Page History

...

To create the snapshot, make sure that the current pom.xml is for a SNAPSHOT version. Perform the following command:

{{mvn deploy \[-DskipTests\]}}

This will create the binary jar(s) and hashes and upload them.

If you want to check that the source and javadoc jars are correct, perform the following:

{{mvn deploy -Prelease Prelease \[-Dgpg.skip\] \[-DskipTests\]}}

This will create the binary, source and javadoc jars and hashes and upload them.

The -Prelease flag is necessary to ensure ensures that the source and javadoc jars are created. The -Dgpg.skip flag skips the signing phase.; do not omit this as it might mislead users if a signed jar was deployed as a snapshot

The resulting snapshot will appear in the Nexus repository under:

...

mvn clean gpg:sign deploy -Ptest-deploy

Creating a Nexus staging release

Make sure you are using Commons Parent V16 or later.

This is necessary to ensure that Nexus is used as the deployment target.

Prepare Your Version Number

A guideline regarding version numbering can be found at http://commons.apache.org/releases/versioning.html - within Commons we reached the following consensus

Note: Per default, the Built-by header in the manifest of the generated jars is filled from your operating system's login ID. If your Apache ID differs from this ID, you can override the Maven default by specifying the user.name property at the command line, e.g.

mvn clean deploy -Prelease-Ptest-deploy

 -Duser.name=<apacheID>

Creating a Nexus staging release

Make sure you are using Commons Parent V16 or later.

This is necessary to ensure that Nexus is used as the deployment target.

Prepare Your Version Number

A guideline regarding version numbering can be found at http://commons.apache.org/releases/versioning.html - within Commons we reached the following consensus

• when your release a new major or minor version it comes without
• when your release a new major or minor version it comes without point release number, e.g "foo-1.0.jar" or "foo-2.1.jar"
• when doing a bugfix release your need to add the point release number, e.g "foo-1.0.jar" or "foo-2.1.jar"
• when doing a bugfix release your need to add the point release number, e.g "foo-1.0.1.jar" or "foo-2.1.1.jar"
  

Prepare Your Maven Variables

...

The commons-build plugin generates the download page in {{./src/site/xdoc/download_\[commons-foo\].xml}} based on {{commons.release.version}}

mvn commons:download-page

Update the release notes

Ensure that the release notes refer to the release version, not snapshot. If using automatic release note generation from changes.xml, the following command should update the file:

...

If you have problems running this command, the following profile in settings.xml may help:

<profile>
  <id>apache-release<<id>release</id>
  <properties>
     <gpg.passphrase></gpg.passphrase>
     <gpg.keyname>your_key</gpg.keyname>
  </properties>
</profile>

...

The site should appear on the specified folder.

Send Out The Vote

Below you find a vote template to save you some time ...Alternatively, you can stage the site in your public_html folder in your home directory on people.apache.org. This can be done with the following command:

Tag:

httpsmvn site:stage-deploy
-DstagingSiteURL=scp://svnpeople.apache.org/reposhome/<ApacheID>/public_html/foo-1.2rc1

Send Out The Vote

Below you find a vote template to save you some time ...

Tag:

https://svn.apache.org/repos/asf/commons/proper/YOUR_PROJECT/tags/${commons.rc.version}

asf/commons/proper/YOUR_PROJECT/tags/${commons.rc.version}

Site:

http://people.apache.org/builds/commons/YOUR_PROJECT/${commons.release.version}/${commons.rc.version}/site/index.html

Binaries:

Add the Nexus URL to your binary artifacts, f. e. https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-compress

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because

...

Check the MD5/SHA hashes!

Also, change the group to commons:

chown :commons *

Copy to dist

On people.apache.org, change directory to the distribution directory for your component:

...

This can be done for instance with the verify_sigs.sh script available under https://svn.apache.org/

...

repos/private/

...

committers/

...

tools/releases (just check out from SVN and place the shell scripts in the bin folder below your home directory).

Also, change the group to commons and ensure that the files can be written by the group:

chgrp commons *
chmod g+w *

Copy to dist

On people.apache.org, change directory to the distribution directory for your component:

cd /www/www.apache.org/dist/commons/foo/

Move source

Move source distributions, their detached signatures and md5 sums into position. All source versions live in the source subdirectory.

mv ~/foo-1.2-RC3/commons-foo-1.2-src* source

Move the binary distributions, their detached signatures and md5 sums into position. All binary source versions live in the binaries source subdirectory.

mv ~/foo-1.2-RC3/commons-foo-1.2-binsrc* binaries
source

Move the binary distributions, their detached signatures and md5 sums into position. All binary versions live in the binaries subdirectory.

mv ~/foo-1.2-RC3/commons-foo-1.2-bin* binaries

Double Double check the permissions for both binaries and source distributions. The file permissions should be "rw-rw-r-" and the group should be "commons", for example:

...

Replace the current RELEASE-NOTES.txt with the new release notes.

Symbolic Links

Remove symbolic links to current distributions

rm commons-foo-current*

Recreate links to current distribution: From committers/tools/releases in the ASF subversion repository, download the script "symlinks.sh" and install it in your home/bin directory. Make sure it is executable and your path includes your /bin subdirectory. From the top level distribution directory (/www/www.apache.org/dist/commons/foo/), execute

symlinks.sh 1.2

where the argument is the number of your version.

Nexus release

1. remove commons-compress-1.1-bin.* and commons-compress-1.1-src.* from nexus staging area
2. Promote
   

These are no longer to be used, so please do not use symbolic links in mirrored directories!

Nexus release

1. remove commons-compress-1.1-bin.* and commons-compress-1.1-src.* from nexus staging area
2. Promote
   

Note that Nexus release is asynchronous - it may take Note that Nexus release is asynchronous - it may take a short while for the files to be copied to the release area of Nexus and for the status to be updated.

...

1. Examine the directory listing page. At the bottom should be found the information you entered into the README.html. Please check that this is correct.
2. Check the KEYS file
3. Check the RELEASE-NOTES.txt
4. Download and verify the current distributions, the following might help committers/tools/releases/verify_sigs.sh.
5. Follow the links to the binaries and source directories. Check them in a similar manner.
   

Publish the website

Run the following to deploy the new component website:

mvn site:deploy

On peopleSee https://commons.apache.org, verify that the directory has been updated, and that the file and directory permissions are correct (readable by all, not writeable by world, but group writeable). Also, ensure that the group is set to 'commons'. For example:

pwd commons.apache.org : ls -l compress
total 1366
drwxrwsr-x  5 niallp     commons      20 Aug 19 07:22 apidocs
-rw-rw-r--  1 grobmeier  commons   21050 Aug 19 09:19 changes-report.html
drwxrwsr-x  5 niallp     commons      98 Aug 19 07:22 cobertura
-rw-rw-r--  1 grobmeier  commons    7555 Aug 19 09:19 conventions.html

Note that the files are transferred to the real web site only every few hours, so it may be a while before you see your changes appear. However if you set your webbrowser's HTTP proxy to 140.211.11.10 port 80 and access http://commons.apache.org/ you should be able to see the changes immediately.

Send announcement

Announce the availability of the new release. Please check that the mirrors have been updated with the new release before sending the announce. There is no need to check all mirrors, but it's worthwhile checking a few of them.

Please remember to give a brief description of your component. Please also remember to remind people about verifying the signatures. The subject should be something like \[ANNOUNCEMENT\] Foo 1.2 Released. Send this mail from your Apache account. Please spell check the document!

Wait to send the release announcement until you have verified that the release artifacts are available on the mirrors.

The component website including the updated download page has been updated on the public site http://commons.apache.org/foo.

If the component publishes maven artifacts, these artifacts have been replicated to the central maven repo at repo1.maven.org. (Clear your local repo of the release artifacts and either activate the clirr report with the updated version info or update a local project with a dependency to the new release version to get maven to try to download the release artifacts. Or just access repo1 using a web browser.) The release announcement should go to (at least) the following mailing lists:

...

/site-publish.html

Send announcement

Announce the availability of the new release. Please check that the mirrors have been updated with the new release before sending the announce. There is no need to check all mirrors, but it's worthwhile checking a few of them.

Please remember to give a brief description of your component. Please also remember to remind people about verifying the signatures. The subject should be something like \[ANNOUNCEMENT\] Foo 1.2 Released. Send this mail from your Apache account. Please spell check the document!

Wait to send the release announcement until you have verified that the release artifacts are available on the mirrors.

The component website including the updated download page has been updated on the public site http://commons.apache.org/foo.

If the component publishes maven artifacts, these artifacts have been replicated to the central maven repo at repo1.maven.org. (Clear your local repo of the release artifacts and either activate the clirr report with the updated version info or update a local project with a dependency to the new release version to get maven to try to download the release artifacts. Or just access repo1 using a web browser.) The release announcement should go to (at least) the following mailing lists:

• announce@apache.org
• dev@commons.apache.org
• user@commons.apache.org
  

Post Release Cleanup

The actual release task is now complete, however there are some remaining steps to do some cleanup and to prepare the next development iteration.

• Remove Obsolete Releases: Unless old versions are especially required, remove them from the dist directory. This will cause the files to also be deleted from the mirrors and save them some diskspace as well as simplifying things for users. Note that the contents of the /www/www.apache.org/dist directory is regularly copied to /www/archive.apache.org/dist and from there transferred to host archive.apache.org. Deleting files from the standard distribution directories does not delete them from the archive dist directories so users will still be able to access old files even when they are not available from the mirrors.
• Update JIRA: Mark the release as released in the JIRA project admin and CLOSE all issues RESOLVED in this release. Make sure the FIX VERSION for all issues closed with this release is set correctly to this version. If this has not already been done, create a JIRA version for the next release.
• Update DOAP file: Update the component's DOAP file with details of the released version:
  

      <release>
        <Version>
          <name>x.y.z</name>
          <created>yyyy-mm-dd</created>
          <revision>x.y.z</revision>
        </Version>
      </release>

• Update changes.xml: If the component uses the maven changes plugin to maintain its changelog, fill in the release date for the just released version and create a new release element for the next release.
• Create the relase tag: Copy the tag of the RC whose vote succeeded to the final release tag, e.g.
  

svn copy https://svn.apache.org/repos/asf/commons/proper/foo/tags/FOO_1.2RC1
  https://svn.apache.org/repos/asf/commons/proper/foo/tags/FOO_1.2 -m "Tagging 1.2 release"

...