Release Management

*This is the release process for Apache Felix, based on Apache Maven process

Basics

Apache Felix artifacts are distributed in two channels: The Maven Repository and the Apache distribution channels.

The basic steps for releasing are:

The Apache Felix PMC appreciates all committers playing release manager for the projects they maintain. Due to restrictions imposed on us, only members of the PMC are actually able to commit the releases to the distribution repository (See Publish the release candidate). In this case please ask a member of the PMC to actually publish the release artifacts. Thanks.

Prerequisites

To prepare or perform a release you MUST BE at least an Apache Felix Committer.

  • each and every release must be SIGNED; your public key should be added to [https://www.apache.org/dist/felix/KEYS] (see Appendix A)

  • 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.5.0 (or higher)

Listing the Apache servers in the settings.xml file also requires adding the password to that file. Starting with Maven 2.1 this password may be encrypted and needs not be give in plaintext. Please refer to Password Encryption for more information.

In the past we staged release candidates on our local machines using a semi-manual process. Now that we inherit from the Apache parent POM version 5, a repository manager will automatically handle staging for you. This means you now only need to specify your GPG passphrase in the release profile of your $\{user.home\}/.m2/settings.xml:

 <settings>
   ...
   <profiles>
     <profile>
       <id>release</id>
       <properties>
         <gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase>
       </properties>
     </profile>
   </profiles>
   ...
 </settings>

Everything else has been configured in the latest Felix parent POM:

 <parent>
   <groupId>org.apache.felix</groupId>
   <artifactId>felix-parent</artifactId>
   <version>6</version>
   <relativePath>../pom/pom.xml</relativePath>
 </parent>

Staging the Release Candidates

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. This is useful for existing builds that still depend on a snapshot version of this artifact. It means that the snapshot they will be getting is effectively the same as the released version.

    $ 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

    $ mvn release:clean
$ mvn release:prepare

    • preparing the release will create the new tag in git, automatically checking in on your behalf

  7. Stage the release for a vote

    $ 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.

Starting the Vote

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

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

Hi,

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

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

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

You can use this UNIX script to download the release and verify the signatures:
https://github.com/apache/felix-dev/blob/master/check_staged_release.sh

Usage:
sh check_staged_release.sh [YOUR REPOSITORY ID] /tmp/felix-staging

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 FELIX JIRA page, select [Release Notes

https://issues.apache.org/jira/secure/ConfigureReleaseNote.jspa?projectId=12310100] 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 FELIX 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 link:{{ refs.project-management-committee-pmc.path }}[{{ refs.project-management-committee-pmc.headers.title }}]

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

To: "Felix Developers List" <dev@felix.apache.org>
Subject: [RESULT] [VOTE] Release Felix 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 Felix 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 rm ...)

  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

INFO: The release manager is free to either reuse the same version when proposing a new release for vote (for example 2.1.2 after a failed 2.1.2 release attempt), or choose a different number (for example 2.1.4 after a failed 2.1.2 attempt). (cf. vote on 02/14/11).

Promoting the Release

If the vote passes:

Upload the Artifacts

If you are not a member of the Apache Felix PMC you might have to ask a member of the PMC to execute this step.

It is recommended to use the check_staged_release.sh script to download your release prior to releasing the staging repository. This will make the task of uploading the release to the Felix releases repository easier.

We use the distribution mechanism as described in How do I upload a release (newer way)?

  1. Check out the Felix releases repository;

  2. svn add the artifacts to your checkout;

  3. svn rm the artifacts from the previous release from your checkout. This will remove the artifacts from the main distribution and the mirrors. They are still kept in the archive;

  4. svn commit your changes.

After committing your changes, the Apache Felix Dist folder is immediately updated. Updating the mirrors takes another few hours (up to a day).

Release to the Maven Repository

  1. Login to Apache Nexus Repository with your Apache SVN credentials;

  2. Click on Staging;

  3. Find your closed staging repository, select it, and click the Release button;

  4. Click on Repositories;

  5. Select the Releases repository;

  6. Validate that your artifacts are all there.

Release Bundles to the OBR

If you’re releasing bundles, you can also add them to the Felix Release OBR. To do this, execute the following command in a checkout of the release tag (target/checkout if is still around, otherwise a new one):

 $ export site=# your checkout of (https://svn.apache.org/repos/asf/felix/site/trunk/content)
 $ export obr=${site}/obr
 $ mvn clean install \
     org.apache.felix:maven-bundle-plugin:deploy \
     -DprefixUrl=https://repo1.maven.org/maven2 \
     -DremoteOBR=releases.xml \
     -DaltDeploymentRepository=apache.website::default::file:///${obr}
 $ svn commit -m"..." ${obr}/repository.xml
the following about the site is wrong and needs to be rewritten

After committing the site must be published. If you release to OBR before updating the site you can defer publishing until after that. Otherwise publish the site by visiting the Site Publication link.

The releases page is updated immediately.

the project building the bundle must use the link:{{ maven-bundle-plugin.path }}[{{ maven-bundle-plugin.headers.title }}] and use a version equal to or higher than 1.4.2.
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>

Update the Site

The appropriate parts of the website are in the https://github.com/apache/felix-antora-site repository or the Apache "original" copy.

  1. Update the news section on the website at News;

  2. Update the appropriate entry in at modules/ROOT/examples/downloads.yml[] to point to the new release;

  3. Commit your changes and push to GitHub (or the Apache mirror);

  4. The published site will be updated by the Jenkins site build jobs.

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.

Publish Generated Documentation

This doesn’t seem to relate well to the state of the CMS site.

This procedure applies currently only to the maven-bundle-plugin:

  1. Checkout the release tag of the plugin

  2. Run mvn clean package site

  3. Clone this https://github.com/apache/felix-antora-site.git repository.

  4. Create a new directory for the new version modules/ROOT/attachments/components/bundle-plugin-archives/bundle-plugin-<version>.

  5. Run git rm modules/ROOT/attachments/components/bundle-plugin/*.

  6. Copy the maven-generated target/site contents to the bundle-plugin and bundle-plugin-<version> directories.

  7. git add the new content.

  8. Commit and push.

Previously undocumented apidocs

Several subprojects appear to have generated javadoc for various versions under modules/ROOT/attachments/apidocs. There are no evident instructions on when or how to update these.

Create an Announcement

To: "Felix Users List" <users@felix.apache.org>
Subject: [ANN] Felix XXX version Y.Z Released

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

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

  https://felix.apache.org/site/apache-felix-XXX.html

This release is available from https://felix.apache.org/site/downloads.cgi and Maven:

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

Release Notes:

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

Enjoy!

-The Felix team

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

Remind Carsten about this release when he writes the next board report ;)

Appendix A: create and add your key to https://www.apache.org/dist/felix/KEYS

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:

 $ 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".</committer>

Second, Add the key to (https://dist.apache.org/repos/dist/release/felix/KEYS).

Only PMC members can commit to files in the dist area, so you should do the key export in the shell commands below, and send the results along to a friendly PMC member for assistance.

Type the following command replacing the word e-mail with your Apache’s one (<committer>@apache.org). To update you have to checkout the Felix dist release repository (you also need this to publish a release):</committer>

 $ (gpg --list-sigs e-mail && gpg --export --armor e-mail) > toadd.key

Provide the file to a PMC member, who will:

 $ svn checkout https://dist.apache.org/repos/dist/release/felix felix-dist
 $ cat toadd.key >> felix-dist/KEYS
 $ scn commit -m"KEYS += <committer>" felix-dist/KEYS

You are now DONE and the changes are visible on https://www.apache.org/dist/felix/KEYS.