...

Create keys needed to sign the release

Notify the community about the upcoming release

Preparing the artifacts

Prepare release notes

Verify Apache requirements are met

Preparing the artifacts

Prepare for a new release

Send a message out to the community indicating that a new release is being planned.  In this message, indicate what is planned for the release and when the release is scheduled.
Give contributors enough time to assimilate this information so they can make plans to deliver their changes.  Recommend giving the community several weeks notice.

Review open issues and planned features; determine which JIRA's should be included in the release.

Verify release requirements are met

Verify the following:

• A DISCLAIMER file exists in the top level directory containing correct information, see http://incubator.apache.org/guides/branding.html#disclaimers
• NOTICE and LICENSE files exist in the top level directory which includes all third party licenses used in the product, see http://www.apache.org/dev/licensing-howto.html for details
• A README file exists and is up to date in the top level directory describing the release
• The source release contains source code only, no binaries
• The provenance of all source files is clear
• All source files have Apache license headers where possible.  Where not possible, then the exceptions are written up in the RAT_README file located in the top level directory
• RAT report is clean
• Copyright dates are current
• Build instructions are provided and can be run successfully
• Test instructions are provided and can be run successfully

Create a release branch and notify community when branch is available

Prior to releasing, send a message to the community indicating that a new release is imminent and that a new branch will be created to build the artifacts.

After the new release branch is created, send another message to the community indicating that the branch is available and the deliveries will be monitored.  Allow deliveries on the main branch to continue.

Verify that all required changes have been delivered.

Create artifacts

Trafodion uses git as its repository.  When a new version is created, mark the repository with the tag to make sure it source tar can be recreated.

Create a tag

Here is an example based on release x.x.x and release candidate 1 (rc1)

  git checkout -b tagx.x.x <release branch name>
  git tag -a x.x.xrc1
  git show x.x.xrc1
  git push apache x.x.xrc1
  git tag 

At this time, a new tag for the current release has been created.  It may take a few days to get the tag updated to all the mirrored repositories.

Create source tar file

  start with a clean git clone and a fresh ssh session
  git checkout -b artifactsx.x.x x.x.xrc1
  cd ../incubator-trafodion
  source ./env.sh
  make package-src
  cd distribution; ls 

At this time, a new source tar file exist in the distribution directory.

Create checksums and signatures for the artifacts

It is assumed that the signer has already created their signing key and registered their public key in the http://pgp.mit.edu pubic repository.

  gpg --armor --output apache-trafodion-x.x.x-incubating-src.tar.gz.asc --detach-sig apache-trafodion-x.x.x-incubating-src.tar.gz
  gpg --verify apache-trafodion-x.x.x-incubating-src.tar.gz.asc
  md5sum apache-trafodion-x.x.x-incubating-src.tar.gz > apache-trafodion-x.x.x-incubating-src.tar.gz.md5
  sha1sum apache-trafodion-x.x.x-incubating-src.tar.gz > apache-trafodion-x.x.x-incubating-src.tar.gz.sha 

Test artifacts

Build and test the source tar file

It is recommended that artifacts be tested following the Building the Software instructions 

• Test build using a fresh VM
• Test build using the tagged version from git

Compare the tagged version with the source tar file

In addition, you should compare the code from the source tar file with the tagged version to make sure they match.
This assumes that  branch artifactsx.x.x contains the proposed artifacts.

  mkdir traf_test
  cd traf_test
  cp .../incubator-trafodion/distribution/*  traf_test/.
  tar zxf apache-trafodion-x.x.x-incubating-src.tar.gz
  compare the two versions, for example using BCompare and the "Folder Compare Report" feature:
    old: ../traf_test/incubator-trafodion 
    new: ../incubator-trafodion

Note: the git version will have some additional git folders and the distribution directory 

Verify Apache requirements

Follow the instructions verifysignature to verify checksums and signatures

Make sure the high level directory contains valid versions of:

• DISCLAIMER.txt
• LICENSE.txt
• NOTICE.txt
• RAT_README.txt
• README.txt

Stage the artifacts

Once all the artifacts have been created and tested, it is time to stage them.  Upload the artifacts to the https://dist.apache.org/repos/dist/dev/incubator/trafodion directory.

...

• sha1sum -c apache-trafodion-x.x.x-incubating-src.tar.gz.sha

• expect:  apache-trafodion-x.x.x-incubating-src.tar.gz: OK

Verify the source tree

• Make a test directory: mkdir trafodion_prep; cd trafodion_prep
• untar the file to the new directory:  tar –xvf apache-trafodion-x.x.x-incubating-src.tar.gz
• Check out the tagged version from git
• Compare the checked out version with the trafodion_prep directory, they should match.  Suggestion - use the bcompare file compare report feature.

Verify Apache requirements

• Make sure that the high level directory contains: DISCLAIMER, NOTICE, LICENSE, README
• Run rat to make sure all files have Apache copyrights

...