This is a draft for a how to about releasing artifacts from Apache Felix:
Most of the work is done by Maven.
Prerequisites
To prepare or perform a release you MUST BE at least a Apache Felix Committer
Each and every release must be signed; therefore the public key should be cross signed by other Apache committers (not required but suggested).
The public key should be added to http://www.apache.org/dist/felix/KEYS![]()
(See Appendix A)
Building the Release Candidates
- Make sure that an appropriate version for the release is entered in Jira
- Build the release artifacts with Maven (the following instructions work on Unix systems, for Windows use a different path than /tmp)
- mvn -Prelease -Darguments="-Prelease -DaltDeploymentRepository=local::default::file:///tmp
![]()
" -DaltDeploymentRepository=local::default::file:///tmp![]()
release:prepare
- mvn -Prelease -Darguments="-Prelease -DaltDeploymentRepository=local::default::file:///tmp
![]()
" -DaltDeploymentRepository=local::default::file:///tmp![]()
release:perform
- The above commands created a tag in svn, deployed the release candidates into your /tmp directory, signed the binaries and created the md5/sha1 files.
- Beautify the checksums (see Appendix B)
- Upload these files to people.apache.org into your home folder and put them there together with the KEYS file containing your public key so we can verify the signatures.
- Start the vote thread, wait 72 hours.
- If the vote fails (easy case first) remove the tag from svn - done
- If the vote is successful, publish the release (see below)
- Create a new version for the artifact in jira.
Publishing the Release
If the vote is successful:
- copy the released artifacts to the dist directory on www.apache.org/dist/felix
- delete the old release there (its archived)
- deploy the release to the maven repository
- 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.
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/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 DONE, but to see the changes on http://www.apache.org/dist/felix/KEYS
![]()
you must wait 2 hours
Appendix B: Beautifying the checksums
The checksum files generated by Maven are not directly usable with all tools. So the following scripts beautify these:
for f in *.md5 ; do g=`echo $f | sed "s/\.md5` ; echo " $g" >> $f ;
done
for f in *.sha1 ; do g=`echo $f | sed "s/\.sha1` ; echo " $g" >> $f ;
done
Appendix B: Script to check releases
Felix Meschberger has developed a set of script aim at testing the file to release. You can find them here:
http://people.apache.org/~fmeschbe/release_helpers/![]()
