Revision: 1805
Author: [email protected]
Date: Thu Jan 7 04:15:06 2010
Log: Incorporate changes in release management process following discussion
on the list.
http://code.google.com/p/simal/source/detail?r=1805
Modified:
/wiki
/wiki/ReleaseManagement.attach/releaseProcessTimeline.gif
/wiki/ReleaseManagement.wiki
=======================================
--- /wiki/ReleaseManagement.attach/releaseProcessTimeline.gif Mon Dec 21
04:24:37 2009
+++ /wiki/ReleaseManagement.attach/releaseProcessTimeline.gif Thu Jan 7
04:15:06 2010
Binary file, no diff available.
=======================================
--- /wiki/ReleaseManagement.wiki Mon Dec 21 04:45:33 2009
+++ /wiki/ReleaseManagement.wiki Thu Jan 7 04:15:06 2010
@@ -1,16 +1,11 @@
#summary Steps to go through for a release
#labels Phase-QA
-*Status: Proposed*
-
-*Note: this page is recently changed to reflect proposed changes to the
release management process. See the
[http://groups.google.com/group/simal-contributors/browse_thread/thread/2a68623b84decde1
simal-contributors list] for details.*
-
= Releases, iterations and timelines =
-We use iterations of two weeks in a cycle of 4 iterations. At the end of
each iteration a new build will be deployed on
http://registry.oss-watch.ac.uk.
-We call this a 'soft release'.
-
-At the end of every third iteration there will be a code freeze to allow
the release manager to create a candidate binary release and create a
release branch for it. This means that every third iteration must assign
sufficient velocity points to the release process to ensure this process is
fully implemented. We cannot cut corners on this as this is where our final
quality control checks are performed.
+We use iterations of two weeks in a cycle of 4 iterations. At the end of
each iteration a new build will be deployed on
http://registry.oss-watch.ac.uk. We call this a 'soft release'. So a soft
release is performed every two weeks.
+
+At the end of every third iteration a release branch will be created and a
candidate binary release is created from that branch. This means that every
third iteration must assign sufficient velocity points to the release
process to ensure this process is fully implemented and all pre-requisites
that are described below are met. We cannot cut corners on this as this is
where our final quality control checks are performed.
The first week of every fourth iteration will be used to test the
candidate binary release and fix critical bugs on the release branch. The
second week of every fourth iteration will then be mainly used for creating
the final binary release itself, which will be signed by as many developers
as possible. At the end of the fourth iteration the binary release will be
made available on the Google Code website and the public registry website
will be updated. During the fourth iteration it is possible to commit
changes to the trunk, but they will not be included in the release at the
end of the iteration.
@@ -25,18 +20,23 @@
The following are the minimal communications that have to take place to
keep to the community informed:
|| *When* || *What* || *To whom* ||
-|| Two weeks before code freeze || Intention to implement a code freeze in
14 days. || [email protected] ||
-|| Three days before code freeze || Intention to implement a code freeze
in 3 days. || [email protected] ||
-|| Day of code freeze || Code freeze has started ||
[email protected] ||
-|| After release branch created || Code freeze has ended ||
[email protected] ||
-|| Candidate binary release uploaded || Binary release available for
testing || [email protected] <br />
[email protected] ||
+|| Two weeks before creating release branch || Intention to create release
branch in 14 days || [email protected] ||
+|| Three days before creating release branch || Intention to create
release branch in 3 days || [email protected] ||
+|| Day before creating release release branch || Intention to create
release branch in 1 day || [email protected] ||
+|| After release branch created || Release branch created ||
[email protected] ||
+|| Candidate binary release uploaded || Binary release candidate available
for testing || [email protected] <br />
[email protected] ||
|| Week after candidate binary release availability || Vote for final
release to be built || [email protected] <br />
[email protected] ||
|| After voting period || Voting results; final release to be built ||
[email protected] <br /> [email protected] ||
|| Final binary release uploaded || Announce availability of final release
|| [email protected] <br /> [email protected] |
|
-= Soft release (1st and 2nd iteration) =
-
-A soft release is created at the end of every first and second iteration.
All that is done for a soft release is an update of the public registry
website (http://registry.oss-watch.ac.uk). See UpdatingDemoServer for
details on how to do that.
+= Soft release (1st, 2nd and 4th iteration) =
+
+A soft release is created at the end of every iteration. However, the
third iteration is a special case because it contains the candidate binary
release. See the next section for details. For every other iteration we
follow the process defined here. The following conditions must be met
before creating the soft release:
+
+ * Check that there are *no critical issues* from the code audit tools
(see CodeAuditing)
+ * All
[http://code.google.com/p/simal/issues/list?can=7&q=&colspec=ID+Type+Status+Priority+Milestone+Summary&x=priority&y=milestone&cells=tiles
unverified issues] have been verified by someone other than the owner of
that issue
+
+If these condition are met, all that is done to perform the soft release
is an update of the public registry website
(http://registry.oss-watch.ac.uk). See UpdatingDemoServer for details on
how to do that.
= Candidate binary release (3rd iteration) =
During the third iteration the focus is on refactoring, testing and bug
fixing in order to ensure the candidate release is ready and all
pre-requisites are met when the code freeze starts at the end of the third
iteration.
@@ -45,7 +45,7 @@
Before a candidate binary release can be made a number of requirements
must be met:
- * Check all CodeAuditing reports are satisfactory (satisfactory means
there are no warnings from the code audit tools)
+ * Check all CodeAuditing reports are satisfactory (satisfactory means
there are *no warnings* from the code audit tools)
* All
[http://code.google.com/p/simal/issues/list?can=7&q=&colspec=ID+Type+Status+Priority+Milestone+Summary&x=priority&y=milestone&cells=tiles
unverified issues] have been verified by someone other than the owner of
that issue
* All source code has been formatted according to the project's coding
standards
* All documentation has been updated to reflect the new features in this
release
@@ -55,13 +55,30 @@
The version numbers of Simal releases are of the form {{{x.y.z}}} or
{{{<major>.<minor>.<micro>}}}. The {{{<major>}}} version number is only
increased when a significan amount of new functionality is added. In this
case the new release version number will be {{{(x+1).0.0}}}. If this is the
case, the scope of the release must be agreed upon by the community using
the voting system on the mailing list.
The {{{<minor>}}} version number is only increased when some functionality
is added to the new release, in which case the new release version number
will be {{{x.(y+1).0}}}. When only bugfixes are part of the new release
there will be a so-called point release. The version number of the new
release in this case will be {{{x.y.(z+1)}}}. Currently, all components
(core, rest and webapp) get the same version number.
-== Code Freeze ==
-
-Send a mail to the developer list stating that the project has entered a
state of code freeze, which means that no changes will be made other than
preparation changes for the next release until the new release has been
tagged.
+== Create a release branch in SVN ==
+
+We must build a release candidate for testing. To do that, we first create
a branch for the new release. Everything for release x.y.z., including the
final release for this version, will then be done from this branch. You can
create a branch with a command similar to this one:
+
+{{{
+svn copy https://simal.googlecode.com/svn/trunk
https://simal.googlecode.com/svn/branches/x.y.z -m "Create branch for the
x.y.z release"
+}}}
+
+Send a mail to the developer list after the branch is created stating that
the release branche is created so that the current status of the trunk will
be the scope of the release.
+
+== Change src version numbers in the trunk ==
+
+We must now set up SVN trunk for development of the next release. To avoid
confusion this should be done immediately after the release branch is
created. We set up the trunk for the next release by correctly setting the
version number for all modules.
+Usually this will mean incrementing the minor version number and setting
the micro version number to '0'.
+
+ * in {{{pom.xml}}} change {{{<version>x.y.z</version>}}} to
{{{<version>x.(y+1).0-SNAPSHOT</version>}}}
+ * in {{{src/main/resources/default.simal.properties}}} change
{{{simal.version=x.(y+1).0-SNAPSHOT}}}
+ * in {{{status.xml}}} add a new {{{<release>}}} element
+
+In addition we need to change the dependency entries for other Simal
modules in both the rest and webapp modules.
== Change version numbers to reflect release build ==
-We must first build a release candidate for testing. To do this we need to
correctly set the version number. Usually this will mean changing the
postfix from "-SNAPSHOT" to "-rc1" in the pom.xml of all the modules and
possibly changing the version number (usually when a point release will be
made).
+All subsequent changes need to be done from the branch. Therefore, the
next step is to ensure your local copy is one from the release branch. You
could for instance checkout the release branch to a fresh workspace. Next,
we need to correctly set the version number. Usually this will mean
changing the postfix from "-SNAPSHOT" to "-rc1" in the pom.xml of all the
modules and possibly changing the version number (usually when a point
release will be made):
* in {{{pom.xml}}} change {{{<version>x.y.z[-POSTFIX]</version>}}}
* in {{{src/main/resources/default.simal.properties}}} change
{{{simal.version=x.y.z[-POSTFIX]}}}
@@ -91,14 +108,6 @@
}}}
Note that the process of building the binaries will run all automated
tests against the code.
-
-== Create a release branch in SVN ==
-
-SVN needs to be tagged with the release information. We first make a
release candidate for the release x.y.z. and all subsequent changes,
including the final release for this version, will be done from this branch:
-
-{{{
-svn copy https://simal.googlecode.com/svn/trunk
https://simal.googlecode.com/svn/branches/x.y.z -m "Tag the x.y.z release"
-}}}
== Upload to Google Code ==
@@ -113,17 +122,6 @@
[UpdatingDemoServer Update the version of Simal] on the demo server
-== Change src version numbers in the trunk ==
-
-We must now set up SVN trunk for development of the next release. To do
this we need to correctly set the version number.
-Usually this will mean incrementing the minor version number, setting the
micro version number to '0' and adding the postfix "-SNAPSHOT".
-
- * in {{{pom.xml}}} change {{{<version>x.y.z</version>}}} to
{{{<version>x.(y+1).0-SNAPSHOT</version>}}}
- * in {{{src/main/resources/default.simal.properties}}} change
{{{simal.version=x.(y+1).0-SNAPSHOT}}}
- * in {{{status.xml}}} add a new {{{<release>}}} element
-
-In addition we need to change the dependency entries for other Simal
modules in both the rest and webapp modules.
-
== Update the Release Notes ==
The ReleaseNotes are used to announce a new release. They are held in the
wiki and are used in email and blog announcements.
--
You received this message because you are subscribed to the Google Groups
"Simal Commits" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/simal-commits?hl=en.
