Re: check with SGML::Parser::OpenSP (and branches)

olivier Thereaux <ot@w3.org> wrote:

>Therefore, I suggest: - that you should commit your changes to CVS. If
>there is something to do to qa-dev to make it work, we'll do it. openSP
>and SPO should realatively easily install from CVS on that system. - that
>Terje should advise on (or proceed with) making a 0_7 branch based on tag
>validator-0_7_0-release

Note that we now have 0.7.x-targetted bugfixes on HEAD past the
«validator-0_7_0-release» tag. So in order to create a clean 0.7.x branch we
need to:

  • Tag current CVS as «validator-0_7-branchpoint».
    — After this point, Björn can check in the SPO code.

  • Create a «validator-0_7-branch» branch from «validator-0_7_0-release».

  • Merge changes between «validator-0_7_0-release» and
    «validator-0_7-branchpoint» onto the tip of the «validator-0_7-branch»
    branch.

  • Tag the tip of «validator-0_7-branch» as «validator-0_7-branchmerge».
    — After this point, further 0.7.x changes can be checked in.

  ° …finish whatever changes are needed to release 0.7.1…

  • Tag then current tip as «validator-0_7_1-release».

  ° …release 0.7.1 in the normal manner from the tag…

  • Merge changes between «validator-0_7-branchmerge» and
    «validator-0_7_1-release» onto the trunk (HEAD).

That convoluted process being a result of unsavory congress with CVS; from that
point on the process would be more like:

  ° …add bugfixes on «validator-0_7-branch» and features on the trunk…
  • CVS tag «validator-0_7_<n>-release».
  ° …release 0.7.n…
  • Merge changes between «validator-0_7_<n-1>-release» and
    «validator-0_7_<n>-release» onto the trunk.

Where the first and third points are just the normal development, the second is
a simple, single, “cvs tag …” command, and the fourth should be almost just a
single “cvs update -j …” command provided nobody goes wild on the 0.7 branch.

That is, it should be a simple, two-step, bullet-point process!

For anyone not doing release engineering the only things to remember are that:
normal development happens on the trunk — which is sometimes labelled with
«HEAD» in CVS command output and CVSWeb — and needs no special attention paid to
branches and tags or other CVS arcana; and if your code is targetted at the
0.7.x releases then you — duh! — need to target the 0.7 branch in CVS.


A vaguely articulated illustration — note “illustration,” not “documentation!” —
of this idea is at <http://qa-dev.w3.org/wmvs/wmv-cvs-branches-v2> (SVG+PNG).


And FWIW Björn's code is looking excellent and I recommend switching to it ASAP.
Provided we don't go crazy on other changes — and we can resurrect the ;outline,
;sp, etc. features in a timely manner — should be a good candidate for 0.8.0
release very quickly. Possibly even quickly enough to obviate the need for a
0.7.2 release.

The only significant hurdle I can see to that is iff we want to consider that
the SPO code requires OpenSP 1.5.2, which isn't released yet, and won't be
available by default on end user systems for quite some time. It also ups the
requirement for Perl from 5.6 to 5.8, but that's been planned a long time and
should present no major obstacle given its penetration.


-- 
 "Oh, my. What? Did I hurt your little, iddy,
  biddy feelings widdle MCSE kind of person?"    -- Tina Holmboe

Received on Monday, 15 August 2005 10:33:01 UTC