W3C home > Mailing lists > Public > public-qa-dev@w3.org > April 2004

Re: [meeting] Notes and log - 2004-04-06

From: Terje Bless <link@pobox.com>
Date: Sat, 10 Apr 2004 23:25:40 +0200
To: olivier Thereaux <ot@w3.org>
Cc: QA Dev <public-qa-dev@w3.org>
Message-ID: <b02010202-1033-9E3446228B3511D893020030657B83E8@[193.157.66.23]>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

olivier Thereaux <ot@w3.org> wrote:

>[[ ACTION - Terje to Document current and planned CVS Branch layout ]]

Ok, here goes... :-)

There are currently two main branches in CVS; HEAD and validator-0_6_0-branch.

«validator-0_6_0-branch» is misnamed; it's really «…-0_6-branch». On this
branch is 0.6.0, 0.6.1, 0.6.2, and 0.6.5 (including betas); and each of them
has a tag corresponding with the version or release number.

HEAD has no (relevant) tags.

The status of «validator-0_6_0-branch» is as we've discussed; it needs some
work to be releaseable, but is otherwise in fairly good shape.

HEAD is in a semi-working state, including major new feature work (Templates
chief among them), but rather far diverged from …-0_6_0-branch and merging
them is going to be a bit of a pain.


The immediate plan once 0.6.5 is out, is to merge 0.6.5 back onto HEAD and
then feature-freeze the …-0_6_0-branch. That is, _only_ absolutely critical
bugfixes — of the type that are then imediately `cvs up`ed on v.w3.org —
should go in after the merge.

Once 0.6.5 and HEAD have been merged, I'm thinking we immediately branch
«validator-0_7-branch». This branch starts out beeing feature-frozen (unlike
0.6.0 did), with only stabilization work getting done. New features that are
well contained and stable get added on HEAD, and the 0.7.0 branch gets merged
back onto the trunk regularly.

The intent is that once 0.7.0 gets released we can, if we have enough new
features yet, immediately branch HEAD into a (feature-frozen) 0.8 branch and
repeat the process.

That way, HEAD is always in a more or less runnable state (roughly alpha
quality) and it never gets too far diverged from the current release train
branch.


Any major and destabilizing work gets done on its own branch; the existing
Template work and the future modularization work beeing prime candidates.

For these branches, whoever makes the branch is responsible for keeping it in
sync with HEAD. Merges happen from HEAD to branch — instead of the other way
around — until the new feature work is ready to be merged back onto HEAD and
integrated into the next version released.


A quick illustration is at <http://qa-dev.w3.org/wmvs/wmv-cvs-branches.png>;
no specific relation to current devel plans, just meant to illustrate the
setup I'm talking about. :-)


Comments?


- -- 
> ...publicity rights, moral rights, and rights against unfair competition...
Well, you've got me there.   I have no idea what any of those have to do with
SGML. Next you'll be claiming that running NSGMLS constitutes an unauthorized
public performance of SGML.                                  -- Richard Tobin

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.0.3

iQA/AwUBQHhmUqPyPrIkdfXsEQKCbgCfYiwEHvYNxgDcHNbfpAhsf7fDcIAAoMCg
GHPeqGVbfIjW22ezx1GgbJyE
=tGkk
-----END PGP SIGNATURE-----
Received on Saturday, 10 April 2004 17:25:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 19 August 2010 18:12:44 GMT