Release Procedures

This checklist should help build a release, and make it available for the public. It is the responsible of the QA to have the release done.

Development release

Phase 1. Initiate code freeze

• Ensure all committed code since last release is reviewed. Simply go through each commit, and check in the review table that this commit is reviewed.
• Ensure all bugs since last release have been evaluated not to block release. Simply go through each bug and check if it has been evaluated.
• Ensure all fixed bugs can be set to status CLOSED. A bug can be set to closed if it has been fixed and reviewed, and has the needed unit tests to verify it is fixed.
• Update dk.netarkivet.common.Constants.BUILDSTATUS to CODEFREEZE
• Commit file to SVN
• Send mail to netarchivesuite-users mailing list about state of code. The mail should contain guidelines to what is allowed and expected during code freeze, and a brief list of important features of the upcoming release.

Phase 2. Release test

• The procedures for running the release test are described elsewhere

Phase 3. Actual release

• Update dk.netarkivet.common.Constants.BUILDSTATUS to RELEASE
• Commit the file to SVN

• Build release packages. It is important to do this on a clean checkout

  svn --username=user co https://gforge.statsbiblioteket.dk/svn/netarchivesuite/trunk netarchivesuite
  cd netarchivesuite
  ant sourcezipball
  ant releasezipball

• Copy the javadoc to the webserver (requires privileges to make a secure-copy to sb-prod-net-001.statsbiblioteket.dk. Thus we need to do this operation from sb-test-acs-001.statsbiblioteket.dk as user 'netarkiv'):

  scp -r docs/apidocs nswiki@sb-prod-net-001.statsbiblioteket.dk:/var/www/html/apidocs/3.3.3

• Rename the binary package to include version name, e.g. mv NetarchiveSuite.zip NetarchiveSuite-3.3.3.zip

• Rename the source package to include version name, e.g. mv NetarchiveSuite-src.zip NetarchiveSuite-3.3.3-src.zip

• Add the release to GForge by going to Files->Admin and choose 'Add release'. Fill out the version number

• Add the two files to the release.

• On http://netarchive.dk/suite/Release_Overview move the last release to http://netarchive.dk/suite/ReleaseArchive

• Add the new release on http://netarchive.dk/suite/Release_Overview

• Write release notes for the release.
• Add to News on wiki
• Send email to netarchivesuite-announce including major features and link to release notes.

Phase 4. End of codefreeze

• Update dk.netarkivet.common.Constants.PATCHVERSION version number with one minor version
• Set BUILDSTATUS to UNSTABLE
• commit file.
• Send end-of-codefree mail to netarchivesuite-devel

Stable release

Basically you need to do the same as when doing a development release, with the following changes and exceptions:

• Different version numbers - ONLY in phase 3 when setting the BUILDSTATUS, increase MINORVERSION with 1 and set PATCHVERSION to 0

• Documentation needs to be moved - See [:Maintaining Documentation:Maintaining_Documentation] under "Making a snapshot"

• Before ending code freeze, build an SVN package for PROD.

Stable patch release

• First fix the bug in the trunk. Make sure the patch is reviewed
• Create a patch

svn diff -r {{patchcommitno-1}}:{{patchcommitno-1}} > fix.patch

• Check out the production branch

  svn checkout --username={{XXX}} https://gforge.statsbiblioteket.dk/svn/netarchivesuite/branches/3.4.0

• Open dk.netarkivet.common.Constants

• Increase the patch number (for instance 3.4.1 to 3.4.2) and set development status to unstable
• Commit
• Apply the patch

patch -p 0 < fix.patch

• Commit
• Review + followup
• Update the development status to codefreeze
• Do release test
• Follow procedures for release as above