Menu
▾
▴
[WWdevel] WeBWorK 2.2 prerelease, code freeze in a branch?
|
From: Sam H. <sh...@ma...> - 2006-01-05 20:44:41
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Guys,
A few of things:
I think this release should be 2.2. It has a few major non-bug-fix
features, like gateway testing (including database changes), the
removal of deprecated database layouts, and jsMath updates (including
the new fonts tarball).
However, in my opinion, we're not ready for a "final" 2.2 release,
since many changes went in after fall semester ended, and therefore
haven't received much testing.
I propose that we release "2.2-pre1" very soon (like today), to give
users a chance to install the new version and work out any kinks on
their local systems, and then fix bugs and make the final 2.2 release
a painless update.
I'd also like to tweak the way we track releases in CVS for this series.
Right now, we do a "feature freeze" in HEAD towards the end of the
release cycle, with the intent that we'll stop adding new features
and concentrate on fixing bugs. The problem is, features creep in
during the freeze, creating more bugs that have to be discovered and
fixed late in the cycle.
When we're satisfied that HEAD is stable, we create a "-patches"
branch, and tag the beginning of the patches branch as our stable
release. Then, we continue to fix bugs on "-patches". Bugs inevitably
also get discovered on HEAD in the course of further development, and
we're supposed to backport those fixes into "-patches" as soon as we
fix them, but we don't. This creates a difficult situation when we
want to make a new release, where we need to backport a LOT of
bugfixes from HEAD to "-patches" all at once. (CVS doesn't make it
very easy to do this, either.)
Here's an illustration:
|<-- development -->|<-- freeze -->|<-- development & bug fixes
- -->
HEAD -----------------------------------
+-------------------------------------->
| /\ /\ /\ /\
| || || || || bug
fixes
| || || || ||
exchanged (or not)
| \/ \/ \/ \/
rel-2-1-patches (branch) +-----------+-----------+----->
|<-- bug -->|<-- bug -->|
| fixes | fixes |
/ / /
/ / /
rel-2-1 rel-2-1-1 rel-2-1-2
I think we can fix this by taking a few steps:
First, 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 HEAD.
It would look like this:
|<-- development -->|<---------- development -------->
HEAD --------------------+------------------------------------------>
| /\ /\ /\ /\
| || || || || bug fixes
| || || || || forward-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
Second, we should do minor (2.x) releases more often, maybe every
four months or so, so that people won't be forced to use HEAD to get
the latest features. We should also do bugfix releases (2.x.y) VERY
often -- if we fix a couple of bugs in a month, it's time for a new
bugfix release.
Third, we should maintain development systems on the release branch
in addition to the HEAD branch. When we do debugging, we should
ALWAYS do it on the release branch. When we fix bugs, we should
ALWAYS commit the fixes to the release branch. My theory is that it's
easier to forward port bugfixes from a branch that only contains
bugfixes than it is to tease bugfixes out of an unstable and rapidly-
changing HEAD and backport them.
Here's a recipe for committing a change to two branches easily. (See
<http://tinyurl.com/dzan3>.) If your current working copy is on the
rel-2-2-dev branch:
cd webwork2
<tweak file "foo">
cvs commit foo # check into rel-2-2-dev
<CVS says, checked in "foo" version 1.10.2.5>
cvs up -A foo # switch to HEAD
cvs up -j 1.10.2.4 -j 1.10.2.5 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 1.10.2.5 and "bar" version 1.5.2.4>
cvs up -A foo # switch to HEAD
cvs up -j 1.10.2.4 -j 1.10.2.5 foo # merge the change for "foo"
cvs up -j 1.5.2.3 -j 1.5.2.4 bar # merge the change for "bar"
<deal with conflicts in both files, if any>
cvs commit foo # check into HEAD
cvs up -r rel-2-2-dev foo # 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.
Fourth, we should establish some definite rules for commits to the
release branch. Of course, only bugfixes should be committed to the
release branch. In addition, each commit should fix a single bug, and
each should mention the Bugzilla bug number for the bug it fixes in
the log message. If we fix a bug that doesn't have a corresponding
bug report, we should create one and mark it fixed immediately. (The
goal here is to be able to describe the changes in a bugfix release
by listing a series of Bugzilla bugs.)
If there are no objections, I'm going to go ahead and branch HEAD as
rel-2-2-dev, and tag the start of the branch as rel-2-2-pre1 and
release it. Let me know your thoughts.
- -sam
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)
iD8DBQFDvYUr14CQX+2WvVgRAnFLAJ4tKI2FJlmmZDqcT7o1i3tJb1oMhgCfZcQO
Gv/m1xtpIXdJFWlzcjhoeyA=
=LV0g
-----END PGP SIGNATURE-----
|
