Differences between revisions 1 and 2
Revision 1 as of 2007-12-14 12:41:55
Size: 1192
Comment:
Revision 2 as of 2007-12-14 13:10:01
Size: 2696
Comment:
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:
Phase 3.  * 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
{{{
  scp apidocs nswiki@kb-prod-net-001.kb.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-src-3.3.3.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.
 * Send email to netarchivesuite-announce including major features and link to release notes.

Phase 4. End of codefreeze

 * Update version number with one minor version
 * Set code status to
 * commit file.
 * Send end-of-codefree mail to netarchivesuite-users
Line 23: Line 54:

 * Different version numbers
 * Documentation needs to be moved

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

  scp apidocs nswiki@kb-prod-net-001.kb.dk:/var/www/html/apidocs/3.3.3

Phase 4. End of codefreeze

  • Update version number with one minor version
  • Set code status to
  • 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
  • Documentation needs to be moved

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