Overview

Documentation

Community

Developers

Related Projects

Apache Software Foundation

How to create and announce a ServiceMix release (v4).

Some of the contents below has not yet been updated to reflect recent changes in Apache infrastructure

Prepare

To prepare and perform a release you must be at least at Apache ServiceMix Committer.

  • each and every release must be SIGNED

  • your public key should also be cross-signed by other Apache committers (not required, but suggested)

  • make sure you have all Apache servers defined in your settings.xml

  • use Maven 3.0.5 or higher

Your settings.xml should look like:

<settings>
  ...
  <profiles>
    <profile>
      <id>release</id>
      <properties>
        <gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase>
      </properties>
    </profile>
  </profiles>
  ...
  <servers>
    <!-- To publish a snapshot of some part of Maven -->
    <server>
      <id>apache.snapshots.https</id>
      <username> <!-- YOUR APACHE SVN USERNAME --> </username>
      <password> <!-- YOUR APACHE SVN PASSWORD --> </password>
    </server>
    <!-- To stage a release of some part of Maven -->
    <server>
      <id>apache.releases.https</id>
      <username> <!-- YOUR APACHE SVN USERNAME --> </username>
      <password> <!-- YOUR APACHE SVN PASSWORD --> </password>
    </server>
    ...
  </servers>
</settings>

Staging the Release Candidate

  1. grab the latest Source

    svn co https://svn.apache.org/repos/asf/servicemix/$PART/trunk

    where $PART is what you want to release. For example, it can be:

    • smx3

    • smx4

    • components

    • ...

  2. prepare your POMs for release:

    1. make sure there is no snapshots in the POMs to be released

    2. make sure everything builds fine

    3. check that your POMs will not lose content when they are rewritten during the release process:

      mvn release:prepare -DdryRun


      and diff the original pom.xml with the one named pom.xml.tag to see if the license or any other info has been removed. This has been known to happen if the starting <project> tag is not a single line. The only things that should be different between these files are the <version> and <scm> elements. If there are any other changes, you must fix the original pom.xml file and commit before proceeding with the release.

    4. publish a snapshot

      $ mvn deploy
...
[INFO] [deploy:deploy]
[INFO] Retrieving previous build number from apache.snapshots.https
...

    • if you experience an error during deployment like a HTTP 401 check your settings for the required server entries as outlined in the Prerequisites

    • be sure that the generated artifacts respect the Apache release rules: NOTICE and LICENSE files should be present in the META-INF directory within the jar. For sources artifacts, be sure that your POM does not use the maven-source-plugin:2.0.3 which is broken. The recommended version at this time is 2.0.4

    • you should verify the deployment under the snapshot repository on Apache

  3. prepare the release

    mvn release:clean
mvn release:prepare

  4. stage the release for a vote
    Note: If you're on Mac OSX 10.5, for a known issue, you need provide your apache svn user/password
    mvn release:prepare -Dusername=ffang -Dpassword=*******

    mvn release:perform

    • the release will automatically be inserted into a temporary staging repository for you, see the Nexus staging documentation for full details

    • you can continue to use mvn release:prepare and mvn release:perform on other sub-projects as necessary on the same machine and they will be combined in the same staging repository

  5. close the staging repository

    • login to https://repository.apache.org using your Apache SVN credentials. Click on Staging on the left. Then click on org.apache.servicemix in the list of repositories. In the panel below you should see an open repository that is linked to your username and IP. Right click on this repository and select Close. This will close the repository from future deployments and make it available for others to view. If you are staging multiple releases together, skip this step until you have staged everything!release_01.png

      |thumbnail!

  6. verify the staged artifacts

    • if you click on your repository, a tree view will appear below. You can then browse the contents to ensure the artifacts are as you expect them. Pay particular attention to the existence of *.asc (signature) files. If you don't like the content of the repository, right click your repository and choose Drop. You can then rollback your release (see Canceling the Release) and repeat the process

    • note the staging repository URL (especially the number at the end of the URL) you will need this in your vote email

Starting the vote

Propose a vote on the dev list with the closed issues, the issues left, and the staging repository - for example:

To: "ServiceMix Developers List" <dev@servicemix.apache.org>
Subject: [VOTE] Release ServiceMix [Component] XXX version Y.Z

Hi,

We solved N issues in this release:
http://issues.apache.org/jira/...

There are still some outstanding issues:
http://issues.apache.org/jira/...

Staging repository:
https://repository.apache.org/content/repositories/servicemix-staging-[YOUR REPOSITORY ID]/

Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Veto the release (please provide specific comments)

This vote will be open for 72 hours.

  • to get the JIRA release notes link, browse to the ServiceMix JIRA page, select Release Notes and choose the relevant sub-project release and format (HTML)

  • to get the list of issues left in JIRA, select the Open Issues tab on the main ServiceMix page, and select the relevant sub-project.

Wait for the Results

From Votes on Package Releases:

Votes on whether a package is ready to be released follow a format similar to majority approval - except that the decision is officially determined solely by whether at least three +1 votes were registered. Releases may not be vetoed. Generally the community will table the vote to release if anyone identifies serious problems, but in most cases the ultimate decision, once three or more positive votes have been garnered, lies with the individual serving as release manager. The specifics of the process may vary from project to project, but the 'minimum of three +1 votes' rule is universal.

The list of binding voters is available at http://servicemix.apache.org/team.html.

If the vote is successful, post the result to the dev list - for example:

To: "ServiceMix Developers List" <dev@servicemix.apache.org>
Subject: [RESULT] [VOTE] Release ServiceMix [Component] XXX version Y.Z

Hi,

The vote has passed with the following result :

  +1 (binding): <<list of names>>
  +1 (non binding): <<list of names>>

I will copy this release to the ServiceMix dist directory and
promote the artifacts to the central Maven repository.

If the vote is unsuccessful, you need to fix the issues and restart the process - see Canceling the Release.
If the vote is successful, you need to promote and distribute the release - see Promoting the Release.

Canceling the Release

If the vote fails, or you decide to redo the release:

  1. remove the release tag from Subversion (svn del ...)

  2. login to https://repository.apache.org using your Apache SVN credentials. Click on Staging on the left. Then click on org.apache.servicemix in the list of repositories. In the panel below you should see a closed repository that is linked to your username and IP (if it's not yet closed you need to right click and select Close). Right click on this repository and select Drop.

  3. rollback the version in the pom.xml and commit any fixes you need to make

Promoting the Release

If the vote passes:

  1. copy the released artifacts to the ServiceMix dist directory (/x1/www/www.apache.org/dist/servicemix) on people.apache.org

  2. delete the old release from the ServiceMix dist directory (it's archived)

  3. login to https://repository.apache.org with your Apache SVN credentials. Click on Staging. Find your closed staging repository, right click on it and choose Promote. Select the Releases repository from the drop-down list and click Promote.

  4. next click on Repositories, select the Releases repository and validate that your artifacts are all there

  5. update the news section on the website at news

  6. update the download page on the website at downloads to point to the new release.

For the last two tasks, it's better to give the mirrors some time to distribute the uploaded artifacts (one day should be fine). This ensures that once the website (news and download page) is updated, people can actually download the artifacts.

Update XML schemas

  • Update the Xml schemas page with a link to the HTML and XSD

Update JIRA

Go to Admin section on the ServiceMix JIRA and mark the Component/Y.Z version as released - create version Y.Z+1, if that hasn't already been done.

Announcing the ServiceMix Release

To: "ServiceMix Developers List" <dev@servicemix.apache.org>
Subject: [ANN] ServiceMix XXX version Y.Z Released

The ServiceMix team is pleased to announce the release of ServiceMix XXX version Y.Z

<<insert short description of the sub-project>>

  http://servicemix.apache.org/XXX.html

This release is available from http://servicemix.apache.org/downloads and Maven:

  <dependency>
    <groupId>org.apache.servicemix</groupId>
    <artifactId>org.apache.servicemix.XXX</artifactId>
    <version>Y.Z</version>
  </dependency>

Release Notes:

<<insert release notes in text format from JIRA>>

Enjoy!

-The ServiceMix team

Remember to forward this announcement to users@servicemix.apache.org - try not to cross-post (CC:) announcements to both user and dev lists.