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
--
<[EMAIL PROTECTED]> | Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-47655 | 81730 Munich, Germany
