Steven Noels wrote:
Carsten Ziegeler wrote:
With respect to the recent thread about release management, I propse a release date of October, 1th which would include a freeze of the cvs starting on monday, 29th.
+1 - let's do a serious freeze this time.
a) Make a 2.1.2 release on October, 1th
+1
Better yet:
Since the process of code freezing is not encouraged, use labels. Start
with the release candidate label first (i.e. marking it now before it changes).
So that would be something like 2_1_2_RC, and if all is good, you can relabel
that exact release 2_1_2_FINAL.
To ensure you have the proper set of sources, you can perform the following
command:
cvs -z3 up -r 2_1_2_RC
After the release is made, you can reset the sticky flag for the release with
cvs -z3 up -a
This process only freezes CVS for the release manager ONLY, allowing work to
move forward for everyone else. If there is a new version of a class or file
that should be incorporated then you can move the RC label to the proper
version.
Does that make sense? It is easier than to enforce a code freeze for all the
committers we have here.
Personally, I prefer code freeze policy. Moving tags on individual files make things messy, and global freeze gives everybody an opportunity to stop for a second, take a look at what we are going to release, and may be fix a bug or too.
Vadim
