Page History

...

it takes at least one week from freeze to ship due to voting, tck testing and potential repeats of that process (re-cut, re-certify, re-vote). There is no reason why work on x.y.z+1 needs to be delayed - only 52 weeks a year.
stronger guarantee no one is updating the branch once frozen
less likely that people and ci systems (continuum) will checkout and build pre-release versions of x.y.z (not x.y.z-SNAPSHOT) which would need to be removed manually and may accidentally be distributed.
it is currently very difficult to roll version numbers forward, entries here and there are often missed. Far better to have branches/x.y have a few straggling old x.y.z-SNAPSHOT versions than a few overlooked x.y.z final numbers that needed to go back to SNAPSHOT - they never leave SNAPSHOT and need to be reverted back later if that process happens in the frozen branch.

...

Creating a Release Candidate

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 release for a vote.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:

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

Also create a zip of the source image.

Create a distribution directory. It should contain the following artifacts for the vote:

Source tar & zip
All assembly images that are part of the vote. This is bot for convenience of the voters and to serve as a distribution location once the vote is complete.
Release notes, README, LICENSE, NOTICE, and DISCLAIMER

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.txt

Note
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.

Copy the entire distribution directory to a publicly accessible location. Put it for a vote along with the staging release you created earlier. In the vote notice, please include the precise names and versions being voted on (e.g. geronimo-jetty6-javaee5-2.1.2) and the svn urls to the current source and where the tag will be created.

Update the plugins site

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 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/</source-repository>

Verify that each entry lists JVM 1.5 and 1.6 targets

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>

Upload the updated geronimo-plugins.xml to the plugin website on people.apache.org
No Format
/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>

Create a distribution directory on people.apache.org (like ~/public_html/releases/geronimo-2.1.3-RC1) and uplod the following artifacts for the vote:
1. Source tar & zip
2. 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.
3. Release notes, README, LICENSE, NOTICE, and DISCLAIMER
4. MD5, SHA1 and ASC files for all of the above

Calling a Vote

Put it up for a vote along with the staging release you created earlier. In the vote notice, please include the precise names and versions being voted on (e.g. geronimo-jetty6-javaee5-2.1.3), the svn revision and urls to the current source along with where the tag will be created.

Start a vote thread for the release

No Format

To: "Geronimo Developers List" <dev@geronimo.apache.org>
Cc: "Geronimo Users List" <user@geronimo.apache.org>
Subject: [VOTE] Release Geronimo Server 2.1.3 RC1

All,

I've prepared a release candidate of Geronimo Server 2.1.3 for your review and vote.

The source for this release candidate is Rev<XXXXX> from the following svn branch:
<branch URL>

When the release vote is approved, I will svn mv the code to:
<future tag URL>

The following staging directory contains the server binary assemblies/distributions to be released (framework, tomcat/jetty, Java EE/Minimal, tar/zip) as well as the RELEASE_NOTES, README, NOTICE, LICENSE and source code archives for the release.
<distribution dir URL>

The maven artifacts for the release can be found here:
<staging-repo URL>
When the release vote is approved, these maven artifacts will be moved
to the m2-ibiblio-rsync-repository at Apache.

[ ] +1 Release Geronimo 2.1.3
[ ] 0 No opinion
[ ] -1 Do not release Geronimo 2.1.3 (please provide rationale)

The voting will be open for 72 hours or until the tck results are verified, whichever is longer.

Start a discussion thread for the vote

No Format


To: "Geronimo Developers List" <dev@geronimo.apache.org>
Cc: "Geronimo Users List" <user@geronimo.apache.org>
Subject: [DISCUSS] Release Geronimo Server 2.1.3 RC1

Discussion thread for "[VOTE] Release Geronimo Server 2.1.3 RC1"

Send out the vote results in a reply email

If the vote passed, send a reply to the original VOTE email with -

No Format


Subject: [RESULTS] Release Geronimo Server 2.1.3 RC1

The vote passed with:

[xx] +1
[xx] +0
[xx] -1

I'll start publishing the artifacts, updating the download website with the new release and create a News entry for our website.

If the vote was canceled and another release candidate is being created for another vote

No Format
Subject: [CANCELED] Release Geronimo Server 2.1.3 RC1 The vote is being canceled due to xxxx and a new release candidate will be created for another vote.

Publishing a Release Candidate

Copy from the staging repo to the production repo.
Once the release is deemed fit for public consumption it can be transfered to a production repository where it will be available to all users. Note: Current version of the stage plugin is 1.0-alpha-1.
Here is an example on how to use the stage plugin:

No Format

mvn stage:copy -Dsource="http://people.apache.org/<your apache id>/staging-repo/<siteId>" \
  -Dtarget="scp://people.apache.org/www/people.apache.org/repo/m2-ibiblio-rsync-repository" \
  -Dversion=2.1.2 \
  -DtargetRepositoryId=apache.releases

Note
The version parameter is currently ignored but specify the correct version anyway. The entire staging repository is synced, not just the given version or the current project.

Note
Also note, this process has been known to have problems at times if a maven version other than 2.0.8 is used.

Copy the distribution content from the staging location to the production repo.
From your people apache account copy the distribution content to the appropriate location under /www/www.apache.org/dist/geronimo/
Info
Ensure that the files you copy to the rsync directory have 0775 dir permission and a 0664 file permission set on them.
Move the branches to tags using the following command.
No Format
svn mv SRC-URL DEST-URL -m "Reason for this commit".
Update the Geronimo site download pages with a new page for the release Geronimo Downloads . Include the list JIRA for know issues by first generating a JIRA query for the release, right clicking on the XML format and saving the url to inclusion in the download page.
Administer the GERONIMO JIRA project to update the released and unreleased versions
Update the Geronimo Home Page with a News item that a new Geronimo Server release is available
Final step is to update the Geronimo Release Roadmaps with the release date.

...

Child pages

Versions Compared

Old Version 11

New Version 12

Key

Creating a Release Candidate

Calling a Vote

Publishing a Release Candidate