Tagging releases

[Martin Kraemer <Ma...@Fujitsu-Siemens.com>]

On Wed, May 29, 2002 at 02:40:12PM -0400, Cliff Woolley wrote:
> 
> If you're going to commit it, just do it.  That's what my preliminary tag
> was for... so I had a base from which to selectively include patches.
> When tagged, APACHE_2_0_37 will != HEAD.  :)

In the good old days, a tag was a tag was a tag. There was no "preliminary
tag" which would then be moved to a different revision later on an
ad-hoc basis.

The way the httpd-2.0 releases work now are IMHO not very professional
from a release management perspective, and users (on dev@) are easily
confused by what's going on.

I hereby propose:

a) a CVS tag is *NEVER* moved.

b) a Release tag is always created as a _branch_ tag first.
   (The tag name could be APACHE_2_0_47_Branch or similar)
    % cvs co httpd-2.0
    % cd httpd-2.0
    % cvs tag -b APACHE_2_0_47_Branch
    % cvs up  -r APACHE_2_0_47_Branch

c) Such a Release Branch Tag is therefore *atomic* relative to the
   Working Tree of the person who is tagging. Even if somebody commits
   in the very same moment of the Branch-Tagging, the tag is still set
   on whatever the person tagging had checked out.

d) if fixes need to be made against such a Release Branch, then they are
   simply committed (on the branch).
    % cvs ci blurb.c
   But only a fraction of the changes made after tagging is relevant
   to fixing the Release. Only these fixes should be applied to the
   Branch. Or, if a fix is made on the branch first, it must also
   be applied to HEAD manually.

e) when the tar ball has been built _and announced_, then a final release
   tag is set on the release _Revision_ (cvs tag without "-b")
    % cvs tag APACHE_2_0_47
   Such a tag can not be moved later.

f) If another release should be necessary (without going to the next
   Apache version for some reason), another name is tagged _on_the_branch_:
    % cvs ci securityfix.c
    % cvs tag APACHE_2_0_47_SecurityFix1

(to be fleshed out in more detail if approved; especially tag naming)

The result is reproducibility (the tag names never move their place)
and easier collaboration (no more "no commits during the next 8 hrs please").

If people want "the 2.0.47" release, they checkout APACHE_2_0_47.
 % cvs co -r APACHE_2_0_47 httpd-2.0
Such a copy cannot be used to commit changes (because a tag is a tag
is a tag, and there cannot be two different versions under one name)

If developers want to update the 2.0.47 (for developing and commiting
a hypothetical security fix1) they checkout the Branch version:
 % cvs co -r APACHE_2_0_47_Branch httpd-2.0
Such a copy _can_ be modified, and changes can be committed.

In ASCII graphics it could look similar to the appended example.
What do you think about this proposal?

   Martin

--------------------------------------
Head Branch 1
 !
 * 1.17
 !\
 ! \
 !  \
 !   \ Branch 1.17.2 aka. "APACHE_2_0_47_Branch"
 !    \
 !     \
 !      \
 !       * 1.17.2.1 (fix against 1.17)
 !       !
 * 1.18  !
 !       !
 !       * 1.17.2.2 (2nd fix)
 !       ! later tagged "APACHE_2_0_47" release tar ball
 * 1.19  !
 !       * 1.17.2.3 (Security Fix applied)
 !       ! later tagged "APACHE_2_0_47_SecurityFix1" release tar ball
 !
 * 1.20 incorporating the fixes from the APACHE_2_0_47_Branch branch
 !
HEAD

-- 
<Ma...@Fujitsu-Siemens.com>         |     Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730  Munich,  Germany

Re: Tagging releases

[Martin Kraemer <Ma...@Fujitsu-Siemens.com>]

On Wed, May 29, 2002 at 11:20:43PM +0200, Kraemer, Martin wrote:
...
I forgot to mention that, with Subversion, it's going to be completely
different again.

   Martin
-- 
<Ma...@Fujitsu-Siemens.com>         |     Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730  Munich,  Germany

Re: Tagging releases

[Cliff Woolley <jw...@virginia.edu>]

On Wed, 29 May 2002, Martin Kraemer wrote:

> On Wed, May 29, 2002 at 02:40:12PM -0400, Cliff Woolley wrote:
>
> In the good old days, a tag was a tag was a tag. There was no "preliminary
> tag" which would then be moved to a different revision later on an
> ad-hoc basis.

I never said it would be moved.  I said ANOTHER tag would be done.  Right
now we have JCW_PRE_2037.  Next we'll have JCW_PRE2_2037, then
JCW_PRE3_2037.  It's just a matter of release candidates in a way.

Roy was very insistent upon this when we were in the 2.0.36 release cycle
(and I agreed), but for 2.0.36 it was too late, we'd already bumped some
tags.

We agreed that from then on, some pre-tag would be done and we'd use
multiple tags to specify subsequent candidates.  When one of those is
selected for release, it gets retagged as APACHE_2_0_xxx.  We could just
spew through version numbers and maybe the next version released after
2.0.36 is 2.0.48, but that doesn't make much sense from the users'
perspective.

> a) a CVS tag is *NEVER* moved.

That has already been agreed upon AFAIK.

> b) a Release tag is always created as a _branch_ tag first.
>    (The tag name could be APACHE_2_0_47_Branch or similar)
>     % cvs co httpd-2.0
>     % cd httpd-2.0
>     % cvs tag -b APACHE_2_0_47_Branch
>     % cvs up  -r APACHE_2_0_47_Branch

-1.  Please let's not go down the branch route.  Merging sucks.  We've
agreed time and time again that we don't want to use CVS branches.

> e) when the tar ball has been built _and announced_, then a final release
>    tag is set on the release _Revision_ (cvs tag without "-b")
>     % cvs tag APACHE_2_0_47
>    Such a tag can not be moved later.

Except for the branch part, that has also already been agreed upon.

> f) If another release should be necessary (without going to the next
>    Apache version for some reason), another name is tagged _on_the_branch_:
>     % cvs ci securityfix.c
>     % cvs tag APACHE_2_0_47_SecurityFix1

We have a hard enough time getting releases out, much less patchlevels.

--Cliff