Changes between Version 4 and Version 5 of Obsolete/Development/ReleaseProcess

Timestamp:

Jul 2, 2014, 11:58:07 AM (11 years ago)

Author:

/C=UK/O=eScience/OU=CLRC/L=RAL/CN=james adams

Comment:

Update to match current procedures.

Obsolete/Development/ReleaseProcess

@@ -8 +8 @@
 As discussed in the 15th Quattor workshop, I detail here the tools and means for a Quattor release.  This document should be kept up to date as the release procedure gets more automated.
 
-For the client code (configuration modules, core libraries...), we do one release each 4-6 weeks.  The "certification" process is manual, here is how it goes:
+We do one release approximately every two months.  The "certification" process is partly automated, here is how it goes:
 
 == Release branch ==
 
-When the time comes, the release manager (RM) creates a new branch in the main GitHub repository, on each repository that will be released.  He ensures that the builds in the [https://jenkins1.ugent.be/view/Quattor Jenkins repository] pass.  If they don't, he iterates with the authors or reverts the commits that break the tests.
+A week before release date, the RM announces a merge freeze on all repositories, this means that no new features should be merged, only fixes for serious issues discovered in the current code-base.
+
+The RM merges any pull-requests that need to be in the release.
+
+If necessary, the release manager (RM) creates a new branch in the main GitHub repository, on each repository that will be released, however most repositories will be released from master.
+
+The RM ensures that the builds in the [https://jenkins1.ugent.be/view/Quattor Jenkins repository] pass.  If they don't, he iterates with the authors or reverts the commits that break the tests.
+
+== Tools ==
+
+The [https://github.com/quattor/release release repository] contains the releaser.sh script for performing releases, this is now the preferred method of performing a Quattor release.
+This builds packages, tags the GitHub repositories, collects and signs the RPMs and generates a signed YUM repository in a tar-ball.
+
+At least one release candidate should be built before a final release, more often than not several will be required!
+
+Release numbering is of the format YY.M.P where P is a point-release number, starting at 0.
+Release candidates are suffixed with -rcN where N is the RC number.
+For example:
+   * 14.5.0  (final)
+   * 14.6.0-rc1  (release candidate 1)
 
 == Testing the release ==
 
-When all tests seem to pass, the RM creates all the packages and uploads them to some Yum repository.  He will then update all templates in a sandbox, and deploy the site.
+When all tests seem to pass, the RM uploads the repository tar-ball to the to yum.quattor.org and publishes it under /testing/.
+
+The RM announces the availability of the RC and requests site testing.
 
 '''NOTE:''' We don't have the manpower to produce test profiles for each component.  Only the most important ones are being stressed ATM.
@@ -22 +43 @@
 '''NOTE:''' We'd appreciate a number of virtual machines (or a test site in the cloud) to make even more thorough tests.
 
-== Declaring victory ==
-
-When all the installations and component executions succeed, the RM executes the following command line on all the repositories:
-
-{{{
-#!sh
-$ mvn -q -DautoVersionSubmodules=true -Dgpg.useagent=true -Darguments=-Dgpg.useagent=true -B -DreleaseVersion=$VERSION clean release:prepare release:perform
-}}}
-
 == Uploading to the Git repositories ==
 
-The [https://github.com/quattor/release.git release repository] contains a POM file with all the artifacts that should be uploaded to the Yum repositories, with their releases.  Just adjust it.
-
-== Tools ==
-
-The `releasing.org` file is an useful checklist to keep track of which modules we have already validated.
-
+The [https://github.com/quattor/release release repository] contains a POM file with all the artifacts that should be uploaded to the Yum repositories, with their releases.  Just adjust it.