Menu
▾
▴
[WWdevel] Re: WeBWorK 2.2 prerelease, code freeze in a branch?
|
From: Michael G. <ga...@ma...> - 2006-01-05 21:09:11
|
On Jan 5, 2006, at 3:44 PM, Sam Hathaway wrote:
> -----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.
>
This sounds just right to me.
> 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.)
>
right. This is the biggest drawback to CVS that I've experienced.
It's the one reason I'd be willing to switch to
more some kind of recent software that supports version development.
> 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.
>
I agree with this -- although it seems to me that this can be done
through CVS update procedures rather than creating
a tar file. You just update to the most recent stable release. We
can notify people periodically about new stable releases if we can
figure out how to maintain a distribution list. Is there anyway we
can maintain a distribution list of folks
that should be notified if we fix some important bug? Does CVS and/
or sourceforge make this feasible?
> 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.
>
OK. We can try this. I suspect that CVS is still not going to allow
this to be an easy operation.
> 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.)
>
We've been doing an ok job in this regard. Every now and then you or
I have gone back and matched up fixes with bugs that were not
reported as resolved. There are a few cases where things get patched
without correlating with a bug report but there are many more where
both a CVS update and a resolution to the bug are done at the same time.
> 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.
fine with me. Go ahead.
Take care,
Mike
> - -sam
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
>
> iD8DBQFDvYUr14CQX+2WvVgRAnFLAJ4tKI2FJlmmZDqcT7o1i3tJb1oMhgCfZcQO
> Gv/m1xtpIXdJFWlzcjhoeyA=
> =LV0g
> -----END PGP SIGNATURE-----
"Only dead fish swim with the stream."
|
