W3C home > Mailing lists > Public > public-qa-dev@w3.org > October 2002

Re: [check] add 'beta' to beta service pages / wrong commit?

From: Terje Bless <link@pobox.com>
Date: Wed, 23 Oct 2002 09:09:58 +0200
To: QA Dev <public-qa-dev@w3.org>
Message-ID: <a01060005-1021-70C85A9FE65611D69D5500039300CF5C@[]>

Olivier Thereaux <ot@w3.org> wrote:

>As suggested by Karl, I tried to add a [beta] flag to the title/banner
>of the beta service.
>Unfortunately I'm yet to be familiar with CVS tagging, and I think I
>commited only to the HEAD, but not to the 0.6.0-beta. I, therefore,
>didn't update the files on :8001.

validator-0_6_0-beta isn't a branch tag, it's a release tag. IOW, that tag
identifies a fixed set of individual revisions of the files in the HEAD
branch. But the files on v.w3.org:8001 were checked out with
"validator-0_6_0-beta" as a "Sticky Tag"; IOW, any "cvs status" or "cvs
update" will only refer to that tag in CVS, not the latest versions.

So to make a never version eligble to update :8001, you need to move the
tag from the version on :8001 to the version you want. You do that by doing
(in this case):

    cvs tag -F validator-0_6_0-beta header.html

Think of it this way: "HEAD" is a branch of development. On this branch we
have the floating checkpoint "validator-0_6_0-beta" which is the latest
code in the beta series. In addition we have a few fixed tags
"validator-0_6_0b2" (and before that, -b1c1 (beta 1, candidate 1)) that
identify a specific release of the beta series.

When we open development on the next version, we'll branch off
"validator-0_6_0-branch" as a branch tag and do new development in HEAD.
Once that code becomes stable we'll branch it off into
"validator-0_7_0-branch". Each branch will have "validator-0_X_X-release"
tags to identify a particular release so we can go back and fix minor bugs.

The released code on :80 will be "subscribed" to the particular release
branch so that a "cvs update" will bring in the latest version of the code
__on_that_branch__ instead of the current development code. That lets
updates be done more often with little chance of snafus, and it won't hold
back development while waiting for the inevitable bug fixes after a new
version is released.

There is of course the caveat that a new repository may be set up where the
version numbers and repository layout changes, but that plan is easily
adoptable still.

Well, or that's what I'm thinking anyways. Y'all feel free to chime in. :-)

"A plague o' both your houses! I am sped." - Mercutio, kinsman to the Prince.
                   See Project Gutenberg <URL:http://promo.net/pg/> for more.
Received on Wednesday, 23 October 2002 03:10:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:23 UTC