Subversion

ローカルの修正は、リリース・ブランチにコミットして、最終リリースのリビジョンをタグします：

svn ci -m "Last-minute fixes for 1.5.1"
svn copy https://svn.codehaus.org/mule/branches/mule-1.5.1 https://svn.codehaus.org/mule/tags/mule-1.5.1 -m "Tag the final 1.5.1 release"

JIRA

1. JIRAにバージョンがリリースされたことを記録（mark）してください。
2. 必要に応じて、新しいバージョンをJIRAに登録してください。

Confluence

リリース・ノート

1. 前のリリース・ノートの形式で、新しいバージョン・リリース・ノート・ページを作成します。
   例：
   http://mule.mulesource.org/wiki/display/MULE/Mule+1.4.1+Release+Notes
2. http://mule.mulesource.org/wiki/display/MULE/Release+Notesを編集して新しいリリース・ノートを書きます。

ダウンロード

1. 配布バージョン毎に、[カウンタ]を作成します。
2. http://mule.mulesource.org/display/MULE/Downloadを編集して、リリースのタイプ（安定、コミュニティ、マイルストーン等）によってリンクを追加しｍす。

資料

バグフィックスのように少を修正しただけでなければ、オンライン資料をPDFをエキスポートして、アップロードします：

1. Confluenceから管理（Administration） -> 高度（Advanced）を選択します。
2. 「スペースのエキスポート」（Export Space）を選択します。
3. 「PDF出力」（PDF Output）を選択します。
4. 「コメントを含む」（Include comments）と「添付をバックアップ」（Backup attachments）の選択を外します
5. 先ず、「全てを解除」（Clear All）を選択した後に、「知恵袋」（Cookbook）と「ESB Muleガイド」（Mule Guieds）を選択し、その下の全てのページも選択します（はい、一ページづつ選択する必要があります）。
6. 「エキスポート」（Export）ボタンを選択します。
7. PDFファイルをローカル・フォルダに保存した後に、https://dav.codehaus.org/dist/mule/docsへアップロードします。

発表

以下の理由でリリースの発表を月曜日に行う方が金曜日に行うよりもよいです。 別の時間帯の人はもう週末のために帰っているかもしれません。 ニュース・コンテンツ-アグリゲーターは更新日付を見ます。最新ニュースとしてリリースされた方が、数日経ったニュースよりもよいです。 項目２と関係しますが、ユーザに多くの更新が届いたとすると、古いニュースはリストの下の方に埋もれます。 開発者は、古い情報よりも新しい情報に反応します。

1. ESB Mule Blogにリリースを発表します。http://mule.mulesource.org/wiki/display/MULE/Homeから「Edit/New/News...」を選択します。
2. Wikiホームページを更新するために、mulesourcedev宛てにメールを出します。（現在、限られた人にしか権限を与えていません。）
3. 以下のリストに、詳細情報ページへのリンクを含めたリリースに付いての短いメールを出します：
   announce@mule.codehaus.org
   user@mule.codehaus.org
   dev@mule.codehaus.org

   メールを出す前に、各@mule.codehaus.orgのメーリングリストに入会する必要があります。

4. メージャ・リリースの場合は、以下のところにも連絡します：
   TheServerside.com
   FreshMeat.net
   JavaLobby.org
5. MuleSourceインフラ・チームに
   会社のダウンロードページを連絡します。会社のホームページを更新してリリースを発表する場合もあります。

一息入れて

自分を褒めて、ビールでも読みましょう！（ビール代はMuleSourceに請求しましょう！）今回のリリースするのが大変だと思ったら、実は前はもっと大変だっとのです。