We should create a release branch
rel-2-2-dev before the feature freeze, and do the freeze on that branch instead of in
HEAD. We can upgrade hosted.webwork and math.webwork to this branch at the same time, to get some serious testing done. If other developers happen to be working on big features at the time, they can continue to do so in
It would look like this:
|<-- development -->|<---------- development ------------------> HEAD --------------------+------------------------------------------> | /\ /\ /\ /\ | || || || || bug fixes forward- | || || || || and back-ported | \/ \/ \/ \/ rel-2-2-dev (branch) *--------------+--------------+------------> (math.webwork and |<-- freeze -->|<-- freeze -->| hosted.webwork run | (bugfixes) | (bugfixes) | this branch) / / / / / / (not a release) rel-2-2-0 rel-2-2-1
Here's how I initially create a new release branch:
# branch the current HEAD as rel-2-2-dev cvs -d /webwork/cvs/system rtag -b rel-2-2-dev webwork2 pg # tag the current rel-2-2-dev as rel-2-2-start, to mark the start of the branch cvs -d /webwork/cvs/system rtag -r rel-2-2-dev rel-2-2-start webwork2 pg
(I'm assuming that no changes have been made to the
rel-2-2-dev branch between the two commands. Maybe we could tag
rel-2-2-start and then branch from that tag instead. That way, we'd have a fixed tag to branch off of. Would that make any difference?)
Developers who wish to help prepare the release and fix bugs should check out a new working copy on the
rel-2-2-dev branch. (Note the custom checkout dir names.)
cvs -d /webwork/cvs/system co -r rel-2-2-dev -d webwork2_rel-2-2-dev webwork2 cvs -d /webwork/cvs/system co -r rel-2-2-dev -d pg_rel-2-2-dev pg
As bugs are fixed in this branch, they should be forward-ported into
HEAD. My theory is that it's easier to forward port bugfixes from a branch that contains only bugfixes than it is to tease bugfixes out of an unstable and rapidly-changing
HEAD and backport them. However, in reality it turns out that most bugs get fixed in
HEAD and then need to be backported into a release branch. I usually end up doing this by looking at the commit logs that have been emailed to me and feeding the diffs into the release branch.
Here's a recipe for committing a change to two branches easily. If your current working copy is on the
cd webwork2 <tweak file "foo"> cvs commit foo # check into rel-2-2-dev <CVS says, checked in "foo" version 220.127.116.11> cvs up -A foo # switch to HEAD cvs up -j 18.104.22.168 -j 22.214.171.124 foo # merge the change <deal with conflicts in "foo", if any> cvs commit foo # check into HEAD cvs up -r rel-2-2-dev foo # go back to rel-2-2-dev
This gets slightly more complex for multiple file commits, since you need a separate merge line for each file:
cd webwork2 <tweak files "foo" and "bar"> cvs commit foo bar # check into rel-2-2-dev <CVS says, checked in "foo" version 126.96.36.199 and "bar" version 188.8.131.52> cvs up -A foo bar # switch to HEAD cvs up -j 184.108.40.206 -j 220.127.116.11 foo # merge the change for "foo" cvs up -j 18.104.22.168 -j 22.214.171.124 bar # merge the change for "bar" <deal with conflicts in both files, if any> cvs commit foo bar # check into HEAD cvs up -r rel-2-2-dev foo bar # go back to rel-2-2-dev
But most bug fixes should be pretty localized, so I think it'll be manageable. If it turns out to be onerous, I can write or find a script to do it automatically.
Later on, when there are Zarro Boogs, we'll tag the current
rel-2-2-0, make tarballs of it, and release them.