Differences between revisions 10 and 11
Revision 10 as of 2008-07-07 07:40:05
Size: 3720
Comment:
Revision 11 as of 2009-05-23 13:27:52
Size: 3811
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Line 6: Line 5:
Line 15: Line 13:
Line 19: Line 16:
Line 31: Line 27:
 * Copy the javadoc to the webserver  * Copy the javadoc to the webserver (requires privileges to make a secure-copy to sb-prod-net-001.statsbiblioteket.dk):
Line 44: Line 40:
Line 51: Line 46:
Line 53: Line 47:
Line 57: Line 50:
 * Documentation needs to be moved - See [:Maintaining_Documentation:] under "Making a snapshot"  * Documentation needs to be moved - See [:Maintaining Documentation:Maintaining_Documentation] under "Making a snapshot"
Line 59: Line 52:
Line 61: Line 53:

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):

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

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-users

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 pacakge 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

ReleaseProcedures (last edited 2011-11-28 12:19:44 by MikisSethSorensen)