...
- Download and install the Gnu Privacy Guard (GPG) from http://www.gnupg.org. Read the documentation on that site and create a key. Have the key signed and verified by others. Submit your public key to http://pgp.mit.edu/. This is a one time process.
- Be sure that you have your
~/.m2/settings.xml
updated as specified above in Releasing a Geronimo Project - Copy (or move as per situation, for eg specs) the trunk/branch to the new branch using the following command.
No Format svn mv SRC-URL DEST-URL -m "Reason for this commit".
- Checkout or update this branches tree on your machine.
- Update the <scm> urls in the
pom.xml
to point to the final url in tags. Eg:Code Block xml xml <scm> <connection>scm:svn:http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1</connection> <developerConnection>scm:svn:https://svn.apache.org/repos/asf/geronimo/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1</developerConnection> <url>http://svn.apache.org/viewvc/geronimo/repos/asf/geronimo/specs/tags/geronimo-servlet_2.5_spec-1.1</url> </scm>
- Add the following release profile to the root pom.xml (Note: This is a subset of the profile included in the maven release process). This will utilize the maven gpg plugin to sign the artifacts produced and the maven deploy plugin to stage the release to your people.apache staging location but will not utilize the maven release plugin to create the tag, rename versions, etc...
Code Block xml xml <profile> <id>release</id> <build> <plugins> <!-- We want to sign the artifact, the POM, and all attached artifacts --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-gpg-plugin</artifactId> <inherited>true</inherited> <configuration> <passphrase>${gpg.passphrase}</passphrase> </configuration> <executions> <execution> <goals> <goal>sign</goal> </goals> </execution> </executions> </plugin> <!-- We want to deploy the artifact to a staging location for perusal --> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-deploy-plugin</artifactId> <inherited>true</inherited> <configuration> <altDeploymentRepository>${deploy.altRepository}</altDeploymentRepository> <updateReleaseInfo>true</updateReleaseInfo> </configuration> </plugin> </plugins> </build> </profile>
- Build the new branches tree as you normally would (including the testsuite) to ensure that it is correct.
No Format mvn install
- After verifying the updated branch can be built and all tests pass, use the rat-maven-plugin to verify that the source contains required license headers.
No Format find . -name target | xargs rm -rf mvn rat:check
Note There are a few source files that cannot contain license headers due to the expected format of the file (like LogFactory classes.) Compare these files against the last release to verify it's okay to release them without headers and ask the prior release manager and/or dev list for guidance.
- Stage the maven artifacts
When you are ready to create a release candidate, clean out the previous build results from the branches tree (otherwise assemblies will not be rebuilt correctly) and rebuild (without tests or testsuite) to now deploy the artifacts to the staging site that will be used for the release vote using the following command.No Format Server 2.0.x/2.1.x - find . -name target | xargs rm -rf mvn -Pstaging deploy Server 2.2 - find . -name target | xargs rm -rf mvn -Prelease,no-it deploy
Note Be extremely careful with this step. There have been times when a slight modification in the above command will result in items being deployed directly to the rsync location rather than to the staging location.
Before running this step, verify that there is a corresponding "staging" or "release" profile in pom.xml.
If there are issues/problems with the deploy to the staging location you may have to stage to a local repository and then scp the content to an apache staging location. - Export and tar/zip the source to be voted on for the release using the following commands:
Also create a zip of the source image.No Format svn export https://svn.apache.org/repos/asf/geronimo/server/branches/2.1.2 geronimo-2.1.2-src tar -zcvf geronimo-2.1.2-src.tar.gz geronimo-2.1.2-src
- Create appropriate md5, sha1, and signatures (asc) for the artifacts added manually. A script similar to this can be used to create the checksums and signature:
Panel title signDist.sh borderStyle solid gpg --print-md MD5 ./geronimo-2.1.2-src.tar.gz > ./geronimo-2.1.2-src.tar.gz.md5
gpg --print-md MD5 ./geronimo-2.1.2-src.zip > ./geronimo-2.1.2-src.zip.md5
gpg --print-md MD5 ./RELEASE_NOTES-2.1.2.txt > ./RELEASE_NOTES-2.1.2.txt.md5
gpg --print-md MD5 ./README.txt > ./README.txt.md5
gpg --print-md MD5 ./NOTICE.txt > ./NOTICE.txt.md5
gpg --print-md MD5 ./LICENSE.txt > ./LICENSE.txt.md5
gpg --print-md MD5 ./DISCLAIMER.txt > ./DISCLAIMER.txt.md5
gpg --print-md SHA1 ./geronimo-2.1.2-src.tar.gz > ./geronimo-2.1.2-src.tar.gz.sha1
gpg --print-md SHA1 ./geronimo-2.1.2-src.zip > ./geronimo-2.1.2-src.zip.sha1
gpg --print-md SHA1 ./RELEASE_NOTES-2.1.2.txt > ./RELEASE_NOTES-2.1.2.txt.sha1
gpg --print-md SHA1 ./README.txt > ./README.txt.sha1
gpg --print-md SHA1 ./NOTICE.txt > ./NOTICE.txt.sha1
gpg --print-md SHA1 ./LICENSE.txt > ./LICENSE.txt.sha1
gpg --print-md SHA1 ./DISCLAIMER.txt > ./DISCLAIMER.txt.sha1
gpg --armor --output ./geronimo-2.1.2-src.tar.gz.asc --detach-sig ./geronimo-2.1.2-src.tar.gz
gpg --armor --output ./geronimo-2.1.2-src.zip.asc --detach-sig ./geronimo-2.1.2-src.zip
gpg --armor --output ./RELEASE_NOTES-2.1.2.txt.asc --detach-sig ./RELEASE_NOTES-2.1.2.txt
gpg --armor --output ./README.txt.asc --detach-sig ./README.txt
gpg --armor --output ./NOTICE.txt.asc --detach-sig ./NOTICE.txt
gpg --armor --output ./LICENSE.txt.asc --detach-sig ./LICENSE.txt
gpg --armor --output ./DISCLAIMER.txt.asc --detach-sig ./DISCLAIMER.txtNote Ensure that your public PGP key is in appropriate public locations (esp. /www/www.apache.org/dist/geronimo/KEYS on people and http://pgp.mit.edu/) and that your pgp key has been signed by several other apache committers to create a web of trust.
Note You will need to copy the RELEASE_NOTES-x.x.x.txt from the target location of one of the built assemblies rather than the root of the branch as the version attributes are updated as part of the build.
- Update the plugins site - http://cwiki.apache.org/GMOxDEV/steps-to-create-a-plugin-repository-for-a-new-geronimo-release.html
- Update your local ~/.m2/repository/geronimo-plugins.xml file from a clean server build to:
- Remove all occurrences of your local repo
No Format <source-repository>~/.m2/repository/</source-repository>
- Verify that each entry points to the 3 2 external repos
No Format <source-repository>http://repo1.maven.org/maven2/</source-repository> <source-repository>http://people.apache.org/repo/m2-snapshot-repository/</source-repository> <source-repository>http://people.apache.org/repo/m2-incubating-repository/</snapshot</source-repository>
- Verify that each entry lists JVM 1.5 and 1.6 targets if the release is prior to 3.0. For all 3.x releases, only 1.6 should be specified.
No Format <jvm-version>1.5</jvm-version> <jvm-version>1.6</jvm-version>
- Update the default repository values by replacing the local repo reference with
No Format <default-repository>http://geronimo.apache.org/plugins/geronimo-2.1.3/</default-repository> <default-repository>http://repo1.maven.org/maven2/</default-repository> <default-repository>http://www.ibiblio.org/maven2/</default-repository>
- Remove all occurrences of your local repo
- Upload the updated geronimo-plugins.xml to the plugin website in svn
No Format https://svn.apache.org/repos/asf/geronimo/site/trunk/docs/plugins/geronimo-2.1.3/ which gets copied over to the following location on people.apache.org by a cron job - /www/geronimo.apache.org/plugins/geronimo-2.1.3
- Create the plugin-repository-list-2.1.4.txt for the on-going maintenance branch with
No Format http://geronimo.apache.org/plugins/geronimo-2.1.4/
- Create the geronimo-2.1.4 directory for the on-going maintenance branch and seed it with a copy of the .htaccess from the prior release and the following geronimo-plugins.xml content (until a 2.1.4-SNAPSHOT build has been published and new geronimo-plugins.xml file created)
No Format <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <geronimo-plugin-list xmlns:ns2="http://geronimo.apache.org/xml/ns/attributes-1. 2" xmlns="http://geronimo.apache.org/xml/ns/plugins-1.3"> <default-repository>http://geronimo.apache.org/plugins/geronimo-2.1.4/</defa ult-repository> <default-repository>http://repo1.maven.org/maven2/</default-repository> <default-repository>http://www.ibiblio.org/maven2/</default-repository> </geronimo-plugin-list>
- Commit the changes to svn
- Update your local ~/.m2/repository/geronimo-plugins.xml file from a clean server build to:
- Create a distribution directory on people.apache.org (like ~/public_html/releases/geronimo-2.1.3-RC1) and upload the following artifacts for the vote:
- Source tar & zip
- All assembly images that are part of the vote. This is more for convenience of the voters and to serve as a distribution location once the vote is complete.
- Release notes, README, LICENSE, NOTICE, and DISCLAIMER
- MD5, SHA1 and ASC files for all of the above
...