Page Edited : FELIX : Release Management (Nexus)
Release Management (Nexus) has been edited by Stuart McCulloch (Apr
22, 2009).
(View changes)
Content:
This is the new release process for Apache Felix, based on the
updated Maven process
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 http://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)
when preparing the release on Mac OS X, make sure you read Appendix
B before continuing
make sure you have all Apache servers defined in your settings.xml
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>1.2.0</version>
<relativePath>../pom/pom.xml</relativePath>
</parent>
Staging the Release Candidates
First prepare your POMs for release:
make sure there are no snapshots in the POMs to be released
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
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
prepare the release
mvn release:clean
mvn release:prepare
preparing the release will create the new tag in SVN, automatically
checking in on your behalf
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
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
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:
http://issues.apache.org/jira/...
There are still some outstanding issues:
http://issues.apache.org/jira/...
Staging repository:
https://repository.apache.org/content/repositories/felix-staging-
[YOUR REPOSITORY ID]/
You can use this UNIX script to download the release and verify the
signatures:
http://svn.apache.org/repos/asf/felix/trunk/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 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
http://felix.apache.org/site/project-management-committe-pmc.html
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:
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.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.
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 Felix dist directory (/www.apache.org/dist/felix
) on people.apache.org
delete the old release from the Felix 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 can also add them to the Felix
Release OBR (see Appendix C).
update the news section on the website
update the download page on the website 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.
Create an Announcement
To: "Felix Developers List" <dev@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>>
http://felix.apache.org/site/apache-felix-XXX.html
This release is available from http://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 us...@felix.apache.org -
try not to cross-post (CC:) announcements to both user and dev lists.
Remind Richard about this release when he writes the next board report
Appendix A: create and add your key to http://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:
Create a public/private pair key:
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"
Add the key to http://www.apache.org/dist/felix/KEYS: type the
following command replacing the word e-mail with your Apache's one
(<committer>@apache.org).
(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
"
You are now DONE, but to see the changes on http://www.apache.org/dist/felix/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: deploying bundles to the Felix OBR
If you're releasing bundles, you can also add them to the Felix
Release OBR. To do this, execute the following command:
mvn clean install \
org.apache.felix:maven-bundle-plugin:deploy \
-DprefixUrl=http://repo1.maven.org/maven2 \
-DremoteOBR=releases.xml \
-DaltDeploymentRepository=apache.releases::default::scp://
people.apache.org/www/felix.apache.org/obr
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.
Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07,
2006) - Bug/feature request
Unsubscribe or edit your notifications preferences
