Subversion

Commit any local modifications on the release branch and tag the final release revision:

JIRA

1. Mark the version as released in JIRA
2. Create more upcoming versions in JIRA if necessary.

Confluence

Release Notes

1. Create a new version release notes page, following the format of previous release notes, e.g. http://mule.mulesource.org/wiki/display/MULE/Mule+1.4.1+Release+Notes
2. Edit http://mule.mulesource.org/wiki/display/MULE/Release+Notes to include the new release notes.

Downloads

I usually ping someone on the marketing web team to do these updates. I just provide the link locations, file sizes + md5 signatures and any extra changes to the page

1. Create a click counter for each distribution.
2. Edit http://mule.mulesource.org/display/MULE/Download and update the info./links as appropriate based on the type of release (stable, community, milestone, etc.).
   1. Move the previous Latest Release from the 'Latest Community Release' section to the 'Previous Releases' section.
   2. Link the new release in the 'Latest Community Release' section. Include file sizes and md5 signatures.
   3. Update the 'Latest Developer' build links to the next version.

Docs

If this is more than a bug fix release, you need to export the on-line docs to PDF and upload them as attachments to the "Offline Documentation" page for each Confluence space. Perform the following steps for each of the relevant spaces in Confluence (MULE2INTRO, MULE2USER, MULE2CB for Mule 2.x):

1. In confluence, go to Edit/Administration/Advanced
2. Choose "Export Space"
3. Select "PDF Output"
4. Unselect "Include comments" and "Backup attachments"
5. Unselect "Offline Documentation" (to avoid recursion
6. Hit the "Export" button
7. Save the PDF locally and upload it as an attachment to the "Offline Documentation" page for the space

Update the download links here: http://www.mulesoft.org/documentation/display/MULE3INTRO/Home

Announcements

It's generally good practice to announce releases on Mondays as opposed to end of week. People in some timezones may already have left for the weekend. News aggregators will pickup the update. It should be hot news on the day it's released and not a few days later. Related to #2. If there are many updates in user's feed (quite natural), the release announcement may get pushed far down the list. It's more likely that developers will quickly respond to initial issues within the first few days after the release.

1. Add an entry to the Mule Blog announcing the release ("Edit/New/News..." from the menu at http://mule.mulesource.org/wiki/display/MULE/Home)
2. Send out a mail to mulesourcedev to update the wiki home page. Currently, this can only be done by a limited circle of persons.
3. Send a brief e-mail announcing the release with a link to get more information, to the following mailing lists: announce@mule.codehaus.org, user@mule.codehaus.org, dev@mule.codehaus.org

   You may need to be subscribed to the @mule.codehaus.org lists in order to send e-mail to them.

4. If this is a major release, also send announcements to TheServerside.com, FreshMeat.net and JavaLobby.org
5. Send a reminder to the MuleSource Infrastructure team that they may want to update the corporate download page as well.

Relax

Give yourself a pat on the back and a beer! (expense the beer to MuleSource, Inc.) If you feel like doing a release was painful, rest assured it used to be much more difficult than it is now!!