Most of the hard work of preparing and deploying the release is done by Maven.
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 6, 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>apache-release</id>
<properties>
<gpg.passphrase> <!-- YOUR KEY PASSPHRASE --> </gpg.passphrase>
</properties>
</profile>
</profiles>
...
</settings>
<parent>
<groupId>org.apache.sling</groupId>
<artifactId>sling</artifactId>
<version>6</version>
</parent>
Starting the Vote
Propose a vote on the dev list with the closed issues, the issues left, and the staging repository - for example:
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 on the Project Team page.
If the vote is successful, post the result to the dev list - for example:
Be sure to include all votes in the list and indicate which votes were binding. Consider -1 votes very carefully. While there is technically no veto on release votes, there may be reasons for people to vote -1. So sometimes it may be better to cancel a release when someone, especially a member of the PMC, votes -1.
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:
- Remove the release tag from Subversion (svn del ...)
- Login to https://repository.apache.org using your Apache SVN credentials. Click on Staging on the left. Then click on org.apache.sling 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.
- Rollback the version in the pom.xml and commit any fixes you need to make
Promoting the Release
If the vote passes:
- Copy the released artifacts to the Sling dist directory (/x1/www/www.apache.org/dist/sling) on people.apache.org
- Delete the old release from the Sling dist directory (it's archived)
- 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.
- Next click on Repositories, select the Releases repository and validate that your artifacts are all there
- If you're releasing bundles, you should also add them to the Sling Release OBR (see Appendix C).
- Update the news section on the website at News
- 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 Manage Versions section on the SLING JIRA and mark the X.Y.Z version as released setting the release date to the date the vote has been closed.
Also create a new version X.Y.Z+2, if that hasn't already been done.
Create an Announcement
Important: Add the release to the Software section of the next board report below Reports.
Related Links
- http://www.apache.org/dev/release-signing.html
- http://wiki.apache.org/incubator/SigningReleases
Considering that 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:
- Create a public/private pair 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"
- Add the key to http://www.apache.org/dist/sling/KEYS: type the following command replacing the word e-mail with your Apache's one (<committer>@apache.org).
- You are DONE, but to see the changes on http://www.apache.org/dist/sling/KEYS you must wait 2 hours
Appendix B: preparing releases on Mac OS X
When running the mvn release:prepare command on Mac OS X, you might see the following error:
[INFO] Executing: svn --non-interactive commit --file /tmp/maven-scm-802409492.commit --targets /tmp/maven-scm-18804-targets
[INFO] Working directory: /homedir/dev/felix/dependencymanager
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to commit files
Provider message:
The svn command failed.
Command output:
svn: Commit failed (details follow):
svn: MKACTIVITY of '/repos/asf/!svn/act/4f11ad5d-9161-0410-b4dd-cb727141ea8c': authorization failed (https://svn.apache.org)
This is due to a bug in Subversion on the Mac, as described by Brett Porter in his blog. He proposes putting an "svn" script at the head of your path to fix the issue.
Appendix C: Deploy bundles on the Sling OBR
We are mainting an OSGi Bundle Repository providing all release of the Sling Bundles. This repository is maintained as part of the Apache Sling site and is available at http://sling.apache.org/obr/sling.xml. The source for this page is maintained in the SVN repository below the site, that is at http://svn.apache.org/repos/asf/sling/site/. To update the Sling OBR repository you must be an Apache Sling Committer since this requires SVN write access.
To update the OBR you may use the Apache Felix Maven Bundle Plugin which prepares the bundle descriptor to be added to the OBR file. Follow these steps to update the OBR:
1. Checkout or update the Site Source
$ svn checkout https://svn.apache.org/repos/asf/sling/site
Note, that you have to checkout the site using the https URL, otherwise you will not be able to commit the changes later.
2. Deploy the Descriptor
To deploy the project descriptor, checkout the tag of the bundle to deploy and run maven
$ svn checkout http://svn.apache.org/repos/asf/sling/tags/the_module_tag
$ mvn clean install \
org.apache.felix:maven-bundle-plugin:deploy \
-DprefixUrl=http://repo1.maven.org/maven2 \
-DremoteOBR=sling.xml \
-DaltDeploymentRepository=apache.releases::default::file:///path_to_site_checkout/obr
This generates the bundle descriptor and adds it to the sling.xml file of your site checkout.
2a. Variant: Refer to Maven Repository
Instead of checking out and building the project locally, you may also use the deploy-file goal of the Maven Bundle Plugin:
$ wget http://repo1.maven.org/maven2/org/apache/sling/the_module/version/the_module-version.jar
$ wget http://repo1.maven.org/maven2/org/apache/sling/the_module/version/the_module-version.pom
$ mvn org.apache.felix:maven-bundle-plugin:deploy-file \
-Dfile=the_module-version.jar -DpomFile=the_module-version.pom \
-DbundleUrl=http://repo1.maven.org/maven2/org/apache/sling/the_module/version/the_module-version.jar \
-Durl=file:///path_to_site_checkout/obr \
-DprefixUrl=http://repo1.maven.org/maven2 \
-DremoteOBR=sling.xml
$ rm the_module-version.jar the_module-version.pom
3. Commite the Site Changes
In the Site checkout folder commit the changes to the obr/sling.xml files (you may also review the changes using the svn diff command).
$ svn commit -m"Add Bundle ABC Version X.Y.Z" obr/sling.xml
4. Update the Site on people.apache.org
After committing the changes, you have to update the site source, which is getting mirrored to the web servers on people.apache.org
$ ssh people.apache.org svn update /x1/www/sling.apache.org/obr/sling.xml
After updating the site source it will generally take an hour or two until the changes are visible on the web.
