Geronimo 2.1.x Release Process
Have 2.1.7 release as an example.
1. Better to use a non-Windows system to create the release candidate
- Dos line endings makes all unix shell scripts unexecutable
2. mvn rat:check
- Dealing with the 2.1.7 release, I found the maven rat plugin(1.0-alpha-3, latest) seems have some bugs.
- incorrect number of unapproved licenses reported by rat:check. This should be resolved in 1.0-alpha-4, but it has not released yet..(http://incubator.apache.org/rat/apache-rat-plugin/changes-report.html)
- If I designated the profile, for example -Pall-subprojects, rat:check won't run in any of the subprojects.
If I designated -Pno-it, rat:check will run only in testsuite subproject.
If I designated -Ptools, which does not contain any subprojects, it will run in all subprojects.
So, the program logic is inverted.. I have to use -Ptools to do rat:check..
3. Manually update some files:
- delete all pom.xml files, and then search "SNAPSHOT"
- Manually check plugin-list url in $SRC\framework\configs\plugin\pom.xml
- update ##VERSION## in README.txt and RELEASE_NOTES.txt
- list JIRAs in RELEASE_NOTES.txt (bugs, improvement, new features, limitations)
- Check the copyright year number in NOTICE file
- commit them
4. mvn release:prepare -DdryRun=true -Pall-subprojects
- Diff the original file 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. Any other changes you must backport yourself to the original pom.xml file and commit before proceeding with the release.
- compare the numbers of pom.xml, pom.xml.tag, pom.xml.releaseBackup
- NOTE: the following 5 pom.xml files won't generate the pom.xml.tag and pom.xml.releaseBackup files
5. Release Prepare
- Before doing release prepare, clean up you local repository to avoid the bad staging release artifacts to be included in the geronimo release. see reference.
- This will update the versions in branch 2.1 and create the release tag
- mvn release:clean -Pall-subprojects
- mvn release:prepare -Pall-subprojects
- you need "mvn clean install -Dstage=bootstrap" in midway
6. Release Perform
- Vote in mailing list, meanwhile wait TCK results. The artifacts up for vote are the geronimo-2.1.x-source-release.tar.gz and geronimo-2.1.x-source-release.zip.
- Post "RESULTxxx" when vote close.
8. Release artifacts
- In Apache nexus, click "release"
- the artifacts will be synchronized to maven central repository in some time.
9. Update geronimo-plugins.xml
10. Upload artifacts to dist
11. Announce in Mailing list and Post news in homepage
12. Update the security advisory page
13. Manaually update files in the 2.1 branch after release
- update 2.1.7 to ##VERSION## in README.txt and RELEASE_NOTES.txt
- remove the JIRA list in RELEASE_NOTES.txt (bugs, improvement, new features, limitations)
- search "2.1.7" and change them to "2.1.8-SNAPSHOT"
- Update artifact-alias, add version 2.1.7 in artifact-alias after 2.1.7 release
- commit them
1. Use Genesis 2.0 as a parent pom
2. Use Maven 2.2.1
It is highly recommended to use Maven's password encryption capabilities for your passwords.http://maven.apache.org/guides/mini/guide-encryption.html
3. Setup PGP Keys (for the ones who be the release manager the first time)
- Download gnupg2
- Generate your PGP Key (refer: http://www.apache.org/dev/openpgp.html) so that maven-release-plugin can sign your built artifacts when do release:perform
- How To Avoid SHA-1
- How To Generate a Strong Key
- Update Maven's settings.xml with following:
- Meanwhile, append your public key to https://svn.apache.org/repos/asf/geronimo/KEYS and people.apache.org:/www/www.apache.org/dist/geronimo/KEYS so that user can verify the artifacts you released.
- gpg --gen-key
- RSA and RSA (default), 4096
- gpg --list-sigs "xxxxxx" && gpg --armor --export "xxxxxx" > xxxxxx.key
- "cat" your public key to above KEYS file