Page History

...

First prepare your POMs for release:

1. Make sure you have correct NOTICE, DEPENDENCIES, and LICENSE files. Remember to update the copyright year.
2. Make sure you have an updated change log file, typically in doc/changelog.txt but in the project root is also acceptable.
3. make sure there are no snapshots in the POMs to be released
4. check that your POMs will not lose content when they are rewritten during the release process
   • mvn release:prepare -DdryRun=true
   • diff the original pom.xml with the one called 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 on 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
5. publish a snapshot

   Code Block
   $ 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
6. prepare the release

   Code Block
   mvn release:clean mvn release:prepare

   • preparing the release will create the new tag in SVN, automatically checking in on your behalf
7. stage the release for a vote

   Code Block
   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 - this is useful when making a release of the Felix framework and its associated bundles.
8. 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.felix 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
9. 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

...

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.felix 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 Felix dist directory (/x1/www/www.apache.org/dist/felix) on people.apache.org
2. delete the old release from the Felix 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. if you're releasing bundles, you can also add them to the Felix Release OBR (see Appendix C).
6. update the news section on the website at news
7. 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.

Promoting the Release

If the vote passes:

1. copy the released artifacts to the Felix dist directory (/x1/www/www.apache.org/dist/felix) on people.apache.org
2. delete the old release from the Felix 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, select it, and click the Release button.
4. next click on Repositories, select the Releases repository and validate that your artifacts are all there
5. if you're releasing bundles, you can also add them to the Felix Release OBR (see Appendix C).
6. update the news section on the website at news
7. 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 JIRA

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

...

Appendix A: create and add your key to http://www.apache.org/dist/felix/KEYS^{Image Removed}

If you are using a *nix system with a working OpenSSH, GnuPG, and bash you can create and add your own key with the following command:

1. Create a public/private pair key:

   Code Block
   gpg --gen-key

   When gpg asks for e-mail linked the key you MUST USE the <committer>@apache.org one
   When gpg asks for comment linked the key you SHOULD USE "CODE SIGNING KEY"
2. Add the key to http://www.apache.org/dist/felix/KEYS:^{Image Removed} type the following command replacing the word e-mail with your Apache's one (<committer>@apache.org).

   Code Block
   (gpg --list-sigs e-mail && gpg --export --armor e-mail) > toadd.key scp toadd.key people.apache.org: ssh people.apache.org "cat toadd.key >> /x1/www/www.apache.org/dist/felix/KEYS"

3. You are now DONE, but to see the changes on http://www.apache.org/dist/felix/KEYS^{Image Removed} you must wait 2 hours

...

The http://felix.apache.org/obr/releases.xml page is automatically updated during the web site synchronization.
Note: the project building the bundle must use the maven-bundle-plugin and use a version superior or equal to 1.4.2.
Note: with Maven 3, you must add an extension to your <build> providing the SCP/SSH protocol:

<build>
...
  <extensions>
   <extension>
     <groupId>org.apache.maven.wagon</groupId>
     <artifactId>wagon-ssh</artifactId>
     <version>1.0-beta-6</version>
   </extension>
   </extensions>  
</build>