You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2001/02/05 02:45:53 UTC
Release Strategy
I have begun to use the release strategy that Roy proposed. What this
means for the future, is that I will be tagging the tree once a weekend
for a long time. :-) I will tag it on the weekend, when I have time, and
the most I will ever ask for is a thirty minute code freeze, just long
enough to check out the code, and lay down the tag. If anybody else wants
to take responsibility for the tagging, just ask. We may be best server
by just having somebody run a cron job every week. Thoughts about that?
I would like us to reach a consensus on the naming scheme we will use, and
how this will work going forward.
Here is my opinion, and I would really like comments.
1) In release.h, we don't modify the AP_SERVER_BASEREVISION macro until
the tree has been accepted. Once it has been accepted, we check out the
tree again using the tag, modify that one file, and re-tag the tree. I
don't believe that will cause any problems, but CVS experts should check
my logic there.
2) For the tag names, I dislike the tag I used this week. I believe that
in the future, the tags should be the date in a format like:
APACHE_2_0_Feb_04_01
This allows us to immediately identify the version of the software we are
using, and know a lot about it. Most of us have a reasonable idea of what
the code looks like, so using dates should make it much easier for us to
track.
3) Once a tree has been accepted as being of release quality, I would
like to see us tag the tree with APACHE_2_0_Beta_1_STABLE or something
like it.
4) I also plan on creating a script that will live in the Apache web
site, which will automatically checkout a specific tag, and roll the
actual release. That script will be created next week sometime, and it
will be used to roll the first actual beta release. This will make it
much easier for people to do the rolling. When I create that script, it
is possible I will need to change the layout of some of the files, I won't
know until I try to create it.
That's it. Comments? Thoughts? Critisims?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Release Strategy
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 05, 2001 at 10:00:23AM -0800, Jim Winstead wrote:
> On Mon, Feb 05, 2001 at 06:55:19AM -0800, rbb@covalent.net wrote:
> > There are two numbering systems remember. The first is what we show the
> > outside world. The second is in ap_release.h, and it does leak between
> > alpha, beta, and release. This number is currently called
> > APACHE_RELEASE. If we are going to get rid of this number, we need to
> > decide that.
>
> actually, what i think roy was getting at is that there aren't two
> numbering systems. you just keep numbering the releases (2.0.0,
> 2.0.1, 2.0.2, etc) which will have the corresponding value in
> APACHE_RELEASE, and then you just label the tarball (or just move
> it into the correct directory under dist). the version used in
> the server header doesn't change.
Yes! I was trying to say the same thing last night, too. There aren't two
numbering systems, there isn't "leakage", there is just *one* set of
numbers.
[ and I also presume that is what Roy was advocating, but I can at least
speak about what I think :-) ]
>...
> the standard process at the company was more traditional (alpha 1,
> alpha 2, .., beta 1, beta 2, .. , release candidate 1, release
> candidate 2, ..). i just numbered the builds, starting with the
> very first one i ever did (build 0).
Microsoft operates this way. Go pull up info on your installed OS. I have NT
on my box, showing "Version 4.0 (Build 1381: Service Pack 6)". That 1381 is
their build number. After it gets qualified, they ship it and call it
version 4.0.
I don't think we need to relabel numbers, though. 2.0.43 is still Apache 2.0.
ActiveState also does builds this way, and Mark Hammond did his PythonWin
build numbering this way. Just use an increasing integer and holes be
damned.
>...
> but instead of the development group suddenly saying "we think
> this is beta 1", the qa department got to say "build 100 meets the
> criteria for beta".
Exactly! +++1 !!
> > Yeah, but that was a dev tree. I would have a lot less trouble doing this
> > if we had a dev tree and a stable tree. I believe that is where we are
> > headed, but that is going to require the new CVS tree to be added.
>
> use branches. i know they get a bad rap around here from some people,
> but putting things in seperate repositories is just ignoring the
> tools that cvs provides to make things easier.
Development branches *are* a bit of a pain. But we're only talking about
tweaking ap_release.h and checking it back in. It is a teeny fork in the
revision history rather than a full-on branch. It should be doable.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: cvs tagging (was: Re: Release Strategy)
Posted by rb...@covalent.net.
> > sure. but when you do a "cvs tag", it tags the versions you have
> > in your sandbox. when someone does a checkout of that tag, they
> > will get what you had in your sandbox. even if someone else had
> > commited something between the time you checked out your sandbox
> > and tagged it. doing it this way just gives you an opportunity to
> > avoid tagging if you've checked out something that is totally broken.
> >
> > i'm just pointing out there's no need to prevent checkins for any
> > amount of time to get this behavior.
>
> Exactly. "cvs rtag" will tag the HEAD in the repository. I could check out
> something from a year ago and then do a "cvs tag" and it will tag *that*
> rather than the HEAD.
>
> The whole point about "freezing the repository" is bogus, given how CVS
> works. Personally, I never pushed because these "freezes" during the tag
> have never impacted what I'm doing. But the myth of needing to "freeze"
> really should stop.
That's what I was asking for. Alright, if we know that it is safe, then I
would remove the freeze step.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
cvs tagging (was: Re: Release Strategy)
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 05, 2001 at 10:29:56AM -0800, Jim Winstead wrote:
> On Mon, Feb 05, 2001 at 01:15:08PM -0500, Greg Marr wrote:
> > At 01:00 PM 02/05/2001, Jim Winstead wrote:
> > >why does the tree ever have to be "frozen", even for ten
> > >minutes? As long as you're doing a "cvs tag" of a checkout and not
> > >a "cvs rtag -r HEAD", you'll never collide with checkins that happen
> > >after you've done your checkout but before you've tagged. they'll
> > >just end up being part of the next tag&roll. no big deal when that
> > >happens on a reliable schedule.
> >
> > What we generally do in our version control system at work is tag
> > first, and then get on that tag, so we're 100% sure that what we're
> > getting is what the next person to get that tag will have.
>
> sure. but when you do a "cvs tag", it tags the versions you have
> in your sandbox. when someone does a checkout of that tag, they
> will get what you had in your sandbox. even if someone else had
> commited something between the time you checked out your sandbox
> and tagged it. doing it this way just gives you an opportunity to
> avoid tagging if you've checked out something that is totally broken.
>
> i'm just pointing out there's no need to prevent checkins for any
> amount of time to get this behavior.
Exactly. "cvs rtag" will tag the HEAD in the repository. I could check out
something from a year ago and then do a "cvs tag" and it will tag *that*
rather than the HEAD.
The whole point about "freezing the repository" is bogus, given how CVS
works. Personally, I never pushed because these "freezes" during the tag
have never impacted what I'm doing. But the myth of needing to "freeze"
really should stop.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Release Strategy
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 01:29 PM 02/05/2001, Jim Winstead wrote:
>On Mon, Feb 05, 2001 at 01:15:08PM -0500, Greg Marr wrote:
> > What we generally do in our version control system at work is tag
> > first, and then get on that tag, so we're 100% sure that what
> we're
> > getting is what the next person to get that tag will have.
>
>sure. but when you do a "cvs tag", it tags the versions you have in
>your sandbox. when someone does a checkout of that tag, they will
>get what you had in your sandbox. even if someone else had commited
>something between the time you checked out your sandbox and tagged
>it. doing it this way just gives you an opportunity to
>avoid tagging if you've checked out something that is totally broken.
Great. I haven't used CVS, only RCS and MS's SourceSafe, neither of
which (as far as I know) track this kind of information (which
version you currently have in your directory), so you have to tag and
then get.
--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: Release Strategy
Posted by Jim Winstead <ji...@trainedmonkey.com>.
On Mon, Feb 05, 2001 at 01:15:08PM -0500, Greg Marr wrote:
> At 01:00 PM 02/05/2001, Jim Winstead wrote:
> >why does the tree ever have to be "frozen", even for ten
> >minutes? As long as you're doing a "cvs tag" of a checkout and not
> >a "cvs rtag -r HEAD", you'll never collide with checkins that happen
> >after you've done your checkout but before you've tagged. they'll
> >just end up being part of the next tag&roll. no big deal when that
> >happens on a reliable schedule.
>
> What we generally do in our version control system at work is tag
> first, and then get on that tag, so we're 100% sure that what we're
> getting is what the next person to get that tag will have.
sure. but when you do a "cvs tag", it tags the versions you have
in your sandbox. when someone does a checkout of that tag, they
will get what you had in your sandbox. even if someone else had
commited something between the time you checked out your sandbox
and tagged it. doing it this way just gives you an opportunity to
avoid tagging if you've checked out something that is totally broken.
i'm just pointing out there's no need to prevent checkins for any
amount of time to get this behavior.
jim
Re: Release Strategy
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 01:00 PM 02/05/2001, Jim Winstead wrote:
>On Mon, Feb 05, 2001 at 06:55:19AM -0800, rbb@covalent.net wrote:
> > What this also means, is that the httpd-2.0 tree is only frozen
> for the
> > ten minutes it takes to tag the tree, I only suggest that, so
> that CVS
> > doesn't get screwed up. If we know that we can tag in the middle
> of
> > somebody committing, then this freeze isn't required. The
> > httpd-2.0-stable tree is frozen always, but a merge from
> httpd-2.0 is
> > allowed at any time, assuming the feature is fully tested in
> httpd-2.0.
>
>why does the tree ever have to be "frozen", even for ten
>minutes? As long as you're doing a "cvs tag" of a checkout and not
>a "cvs rtag -r HEAD", you'll never collide with checkins that happen
>after you've done your checkout but before you've tagged. they'll
>just end up being part of the next tag&roll. no big deal when that
>happens on a reliable schedule.
What we generally do in our version control system at work is tag
first, and then get on that tag, so we're 100% sure that what we're
getting is what the next person to get that tag will have.
--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: Release Strategy
Posted by Jim Winstead <ji...@trainedmonkey.com>.
On Mon, Feb 05, 2001 at 06:55:19AM -0800, rbb@covalent.net wrote:
> There are two numbering systems remember. The first is what we show the
> outside world. The second is in ap_release.h, and it does leak between
> alpha, beta, and release. This number is currently called
> APACHE_RELEASE. If we are going to get rid of this number, we need to
> decide that.
actually, what i think roy was getting at is that there aren't two
numbering systems. you just keep numbering the releases (2.0.0,
2.0.1, 2.0.2, etc) which will have the corresponding value in
APACHE_RELEASE, and then you just label the tarball (or just move
it into the correct directory under dist). the version used in
the server header doesn't change.
i understand this can be tough for people stuck in the
alpha/beta/whatever mentality to wrap their heads around. on
the last big software package i worked on (an educational game),
i instituted a process very similar to what i think roy has proposed.
the standard process at the company was more traditional (alpha 1,
alpha 2, .., beta 1, beta 2, .. , release candidate 1, release
candidate 2, ..). i just numbered the builds, starting with the
very first one i ever did (build 0).
it drove some people nuts. we released build 200 or so to
manufacturing (and then we used build/patch 220 for fixing up the
online play), since i did builds often, 'skipping' numbers when i
found problems after i had tagged and before i released it to anyone.
but instead of the development group suddenly saying "we think
this is beta 1", the qa department got to say "build 100 meets the
criteria for beta".
> Yeah, but that was a dev tree. I would have a lot less trouble doing this
> if we had a dev tree and a stable tree. I believe that is where we are
> headed, but that is going to require the new CVS tree to be added.
use branches. i know they get a bad rap around here from some people,
but putting things in seperate repositories is just ignoring the
tools that cvs provides to make things easier.
but i would really go without seperate trees/branches for a little
while just to see how it goes. the worst that happens is that you
do a few tag&rolls that couldn't even be considered alpha-quality.
if you at least do a test compile before you tag, you can avoid even
tagging builds that would be totally broken. (but you'll still end
up with things like the os/2 build being broken, sometimes.)
> What this also means, is that the httpd-2.0 tree is only frozen for the
> ten minutes it takes to tag the tree, I only suggest that, so that CVS
> doesn't get screwed up. If we know that we can tag in the middle of
> somebody committing, then this freeze isn't required. The
> httpd-2.0-stable tree is frozen always, but a merge from httpd-2.0 is
> allowed at any time, assuming the feature is fully tested in httpd-2.0.
why does the tree ever have to be "frozen", even for ten minutes?
as long as you're doing a "cvs tag" of a checkout and not a "cvs
rtag -r HEAD", you'll never collide with checkins that happen after
you've done your checkout but before you've tagged. they'll just
end up being part of the next tag&roll. no big deal when that
happens on a reliable schedule.
jim
Re: Release Strategy
Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
"Roy T. Fielding" wrote:
>
> Just tag the tree with the version number and let it be built before
> deciding whether or not it is alpha/beta/gold, and don't cry over the
> loss of a few build numbers as a result of overactive commits.
+1
--
#ken P-)}
Ken Coar <http://Golux.Com/coar/>
Apache Software Foundation <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed" <http://ApacheUnleashed.Com/>
Re: Release Strategy
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
The model I am talking about was used by the Apache Group throughout
the first year of development, with the exception that we were not
using CVS at the time and thus the patch and build process was slower.
I've explained what I intend to do in as many ways as I can. It isn't
brain surgery. It is a simple matter of adding a little laxative to
the thought process that is currently going on in the minds of the RMs.
Just tag the tree with the version number and let it be built before
deciding whether or not it is alpha/beta/gold, and don't cry over the
loss of a few build numbers as a result of overactive commits.
I have put far more thought into this than was ever placed in the
current process of calling things alpha or beta. Go back in the
archives for the 1.2 releases and see for yourself. I've been asking
for this change for over three years now. Personally, I'm tired of
being prevented from improving our development process. It is broken.
Until you propose something that is better, I will proceed with something
I believe will work better than the current process. If it doesn't
work, then we'll change it again, and keep changing it until we get
it right. But I am not going to do a field study and write a
dissertation on the subject just because you aren't sure it will work.
I can't even be "sure" that it will work myself -- it is an experiment.
The only question in my mind was whether or not the group felt the
current process was broken, and that was answered with a resounding
"Yes".
> My current problem with this discussion is that I do not see how this
> model works. I would really like to see an example of this model in
> practice in an Open Source project.
I don't know of any. I don't know of any open source project outside
of Apache that had even remotely comparable quality of code as that
of the original Apache development process. Not even close.
> I am personally not going to be comfortable with this model until I see
> such an example. I would back the PHP model 100%, because I have worked
> it out in my mind, and I see how it all fits together. I also know from
> watching PHP that it seems to work, at least it did for the last release
> (the one I was watching).
No process that produces two different code bases with the same version
number can be said to work. PHP is doing what I proposed *except* that
they allow development to occur after the version has been tagged by
branching the tree into release candidates. I don't like that model
because it is equivalent to having four version components (the last
one being the rc or patchlevel number, which hasn't been consistently
communicated to the user yet because that process is still being learned).
I think three version components is plenty.
> I have thought about the model that is being proposed, and I have outlined
> my problems with it. I have not been able to reconcile the problems I
> have with what has been posted on the list.
>
> I would appreciate one of two things. 1) A very well thought out
> description for how this all works, assuming the tree never freezes, and
> developers intermix bug fixes with bugs. 2) An example of an open source
> project that uses this model so that I can look at what has happened in
> the past with that project.
>
> I believe that either one of those two options would be a very good way to
> prove this model against the real-world. I would also be very happy to
> listen to some other method for proving how this model would work. I am
> very reluctant to use this model without first measuring it against some
> other real-world benchmarks.
I already provided (1), well enough that two other people had no problem
interpreting what should be done even though I was off-line for the
weekend. I'd honestly like to stop arguing about it now so that I can
get back to fixing buildconf.
....Roy
Re: Release Strategy
Posted by rb...@covalent.net.
My current problem with this discussion is that I do not see how this
model works. I would really like to see an example of this model in
practice in an Open Source project.
I am personally not going to be comfortable with this model until I see
such an example. I would back the PHP model 100%, because I have worked
it out in my mind, and I see how it all fits together. I also know from
watching PHP that it seems to work, at least it did for the last release
(the one I was watching).
I have thought about the model that is being proposed, and I have outlined
my problems with it. I have not been able to reconcile the problems I
have with what has been posted on the list.
I would appreciate one of two things. 1) A very well thought out
description for how this all works, assuming the tree never freezes, and
developers intermix bug fixes with bugs. 2) An example of an open source
project that uses this model so that I can look at what has happened in
the past with that project.
I believe that either one of those two options would be a very good way to
prove this model against the real-world. I would also be very happy to
listen to some other method for proving how this model would work. I am
very reluctant to use this model without first measuring it against some
other real-world benchmarks.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Release Strategy
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> I personally believe that an aribtrary number is less useful than a number
> that has some basis for why it was chosen.
There is nothing arbitrary about a version number. I'll add the
documentation for what the major.minor.build numbers mean to the
include file.
> > I was workng under the assumption that we would want to distinguish between
> > servers built from our official release tarball versus those built from
> > a CVS checkout.
>
> Why? If Covalent (or IBM or RedHat or Suse or ...) wants to checkout an
> exact copy of Apache 2.0.1 and build that tree without any changes, why
> shouldn't that get the same version number as the tarball created by
> us?
Because I don't trust that anyone is capable of exactly reproducing
a tarball every time, regardless of the tag. I don't have that much
faith in all versions of CVS on all platforms that people use it.
Our policy has always been to test the tarball created by the RM.
> Even more to the point, if I want to put a server on my home machine,
> and I regularly update against CVS, why can't I use my own CVS checkout
> instead of having to download a complete tarball?
You can. You just don't get the official release version string in
the Server field. I don't see the big deal, but I am willing to drop
that idea and just stick with the -dev/bump/tag/-dev process if that
is what people prefer.
But this doesn't stop testers from having to download the tarball.
> I agree we want to make sure that versions that have been patched don't
> use the same version string as those we deem as good, but I don't
> understand why we want to give people a single option for downloading the
> release tarball. That makes it very difficult to download a release
> version of the server, use it for the production site, and update it with
> patches for testing against.
The tag is still there for cvs checkouts -- the only thing that would have
been different is the default Server string.
....Roy
Re: Release Strategy
Posted by rb...@covalent.net.
> > What is your concern with date-based tags?
>
> I don't have any need of them if the version number is assigned
> at the time of tagging. That is the only type of tag I need.
I personally believe that an aribtrary number is less useful than a number
that has some basis for why it was chosen.
> > > The alpha beta distinction should never be in CVS. There are a couple
> > > other things that need to be changed to make this possible, but they
> > > are trivial. Granted, I had no way for someone to checkout a tagged
> > > revision and get the same exact server-string as that version built
> > > by us, but I thought that was a good thing. The only difference is
> > > that the builder of the official version tweaks the definition
> > > of one symbol in ap_release.h as part of the build script. I'll show
> > > you what I mean when I get back from lunch.
> >
> > I understand how this would be done, but I dislike it. I would like to
> > know that I can checkout an exact copy of B1 from CVS without having to
> > modify anything. That is a concern of mine, so that this is a very
> > reproducable build.
>
> I was workng under the assumption that we would want to distinguish between
> servers built from our official release tarball versus those built from
> a CVS checkout.
Why? If Covalent (or IBM or RedHat or Suse or ...) wants to checkout an
exact copy of Apache 2.0.1 and build that tree without any changes, why
shouldn't that get the same version number as the tarball created by
us? Even more to the point, if I want to put a server on my home machine,
and I regularly update against CVS, why can't I use my own CVS checkout
instead of having to download a complete tarball?
I agree we want to make sure that versions that have been patched don't
use the same version string as those we deem as good, but I don't
understand why we want to give people a single option for downloading the
release tarball. That makes it very difficult to download a release
version of the server, use it for the production site, and update it with
patches for testing against.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Release Strategy
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> What is your concern with date-based tags?
I don't have any need of them if the version number is assigned
at the time of tagging. That is the only type of tag I need.
> > The alpha beta distinction should never be in CVS. There are a couple
> > other things that need to be changed to make this possible, but they
> > are trivial. Granted, I had no way for someone to checkout a tagged
> > revision and get the same exact server-string as that version built
> > by us, but I thought that was a good thing. The only difference is
> > that the builder of the official version tweaks the definition
> > of one symbol in ap_release.h as part of the build script. I'll show
> > you what I mean when I get back from lunch.
>
> I understand how this would be done, but I dislike it. I would like to
> know that I can checkout an exact copy of B1 from CVS without having to
> modify anything. That is a concern of mine, so that this is a very
> reproducable build.
I was workng under the assumption that we would want to distinguish between
servers built from our official release tarball versus those built from
a CVS checkout.
> > BTW, 1.3 is our STABLE branch. 2.0 is our CURRENT branch, and will
> > remain so until we decide it is more stable than 1.3.
>
> I disagree with this. Those are two incredibly different code bases. If
> this was true, then we would be doing a much better job of porting fixes
> from 1.3 to 2.0. In reality, we have done an absolutely horrible job of
> getting patches from 1.3 to 2.0. I would instead compare 1.3 to FreeBSD's
> 4.2 tree and 2.0 to FreeBSD's 5.0 tree. I truly believe that our dev and
> our stable trees need to look similar, or it isn't possible to build
> easily move patches between the two.
It doesn't need to be easy to move changes between the two. I was simply
stating a fact -- 1.3 is our stable tree, 2.0 is our current tree, and
there is no magic that will make 2.0 the stable tree before it is a
stable tree. After 2.0 is stable, someone will create a 2.1 tree for
the next current. Or maybe a 3.0 tree.
....Roy
Re: Release Strategy
Posted by rb...@covalent.net.
> > > Yikes, spend a day off-line and things just start flying. My intention
> > > was to tag the tree whenever some real person felt that it was worth
> > > tagging. -1 (non-veto) on cron-based tags. -1 (non-veto) on date-based
> > > tags. Tags are cheap, but they aren't free (just look at some of the
> > > older RCS files).
> >
> > What is your concern with date-based tags?
>
> They aren't free. Do you plan to vi foo,v 1284dd to strip down tags when you
> move a file :-?
I didn't mean one tag per day, I was simply refering to using the date as
the tag.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Release Strategy
Posted by "William A. Rowe, Jr." <wr...@covalent.net>.
From: <rb...@covalent.net>
Sent: Monday, February 05, 2001 1:18 PM
> > Yikes, spend a day off-line and things just start flying. My intention
> > was to tag the tree whenever some real person felt that it was worth
> > tagging. -1 (non-veto) on cron-based tags. -1 (non-veto) on date-based
> > tags. Tags are cheap, but they aren't free (just look at some of the
> > older RCS files).
>
> What is your concern with date-based tags?
They aren't free. Do you plan to vi foo,v 1284dd to strip down tags when you
move a file :-?
How about deleting the tags on any snapshot that never makes alpha/beta/release?
That means we have 52 tags per year (concievably, probably less.)
I realize we have never been big on killing tags, but if they serve no purpose
long term, lets clean them up?
Re: Release Strategy
Posted by rb...@covalent.net.
> Yikes, spend a day off-line and things just start flying. My intention
> was to tag the tree whenever some real person felt that it was worth
> tagging. -1 (non-veto) on cron-based tags. -1 (non-veto) on date-based
> tags. Tags are cheap, but they aren't free (just look at some of the
> older RCS files).
What is your concern with date-based tags?
> The alpha beta distinction should never be in CVS. There are a couple
> other things that need to be changed to make this possible, but they
> are trivial. Granted, I had no way for someone to checkout a tagged
> revision and get the same exact server-string as that version built
> by us, but I thought that was a good thing. The only difference is
> that the builder of the official version tweaks the definition
> of one symbol in ap_release.h as part of the build script. I'll show
> you what I mean when I get back from lunch.
I understand how this would be done, but I dislike it. I would like to
know that I can checkout an exact copy of B1 from CVS without having to
modify anything. That is a concern of mine, so that this is a very
reproducable build.
> BTW, 1.3 is our STABLE branch. 2.0 is our CURRENT branch, and will
> remain so until we decide it is more stable than 1.3.
I disagree with this. Those are two incredibly different code bases. If
this was true, then we would be doing a much better job of porting fixes
from 1.3 to 2.0. In reality, we have done an absolutely horrible job of
getting patches from 1.3 to 2.0. I would instead compare 1.3 to FreeBSD's
4.2 tree and 2.0 to FreeBSD's 5.0 tree. I truly believe that our dev and
our stable trees need to look similar, or it isn't possible to build
easily move patches between the two.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Release Strategy
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
Yikes, spend a day off-line and things just start flying. My intention
was to tag the tree whenever some real person felt that it was worth
tagging. -1 (non-veto) on cron-based tags. -1 (non-veto) on date-based
tags. Tags are cheap, but they aren't free (just look at some of the
older RCS files).
Like Greg and JimW said, the tag should be a normal three-part version
number. The original intention of the last number was that it should
change whenever we did a build that was at all different from the
previous build. That means the next version is 2.0.0 and we go
from there.
The alpha beta distinction should never be in CVS. There are a couple
other things that need to be changed to make this possible, but they
are trivial. Granted, I had no way for someone to checkout a tagged
revision and get the same exact server-string as that version built
by us, but I thought that was a good thing. The only difference is
that the builder of the official version tweaks the definition
of one symbol in ap_release.h as part of the build script. I'll show
you what I mean when I get back from lunch.
I don't just dislike CVS branches -- I know for a fact that they do not
work for major changes. The CVS method of having all revision info
located in current repository files just doesn't work well for
extended branches. The CVS log becomes crap to read, the RCS files
become fragile as hell, and the whole repository becomes much harder
to checkout and commit changes. BUT this only applies to major changes.
Minor things like making a branch for a release work pretty well,
though I find them unnecessary unless development on HEAD is rapid.
In any case, the branch doesn't need to be made until after a
branch is needed -- we only need the version tag.
BTW, 1.3 is our STABLE branch. 2.0 is our CURRENT branch, and will
remain so until we decide it is more stable than 1.3.
....Roy
Re: Release Strategy
Posted by rb...@covalent.net.
> > Well, one major problem is that our own internal numbering system
> > at present "leaks" into our official release version number...
> > Tags with date stamps (APACHE_2_0_0_FEB_02_00) seem like
> > good ideas, as anyone has had to deal with "now what date on
> > 4-2-STABLE is OK?" knows :)
>
> There is no "leakage" because there is no internal vs external numbering.
> The next time we tag/roll, it should be called 2.0.1. The time after that,
> it will be 2.0.2. etc.
There are two numbering systems remember. The first is what we show the
outside world. The second is in ap_release.h, and it does leak between
alpha, beta, and release. This number is currently called
APACHE_RELEASE. If we are going to get rid of this number, we need to
decide that.
> The point is to get away from the notion of 2.0(alpha,beta,your-mom) type
> numbering and just start zooming through the numbers. It will make the
> process much easier.
>
> Want a comparison? Did you try installing Linux kernel 2.3.1? How about
> 2.3.2? hehe... I didn't think so. But a number of people *did* install them
> somewhere around 2.3.51 (IIRC) as that was relatively stable compared to the
> rest of them.
Yeah, but that was a dev tree. I would have a lot less trouble doing this
if we had a dev tree and a stable tree. I believe that is where we are
headed, but that is going to require the new CVS tree to be added.
So, what if I do this today?
create httpd-2.0-stable cvs tree on deadalus. Work continues on
httpd-2.0, when we tag and roll, the tarball goes to
dev.apache.org/dist/unreleased.
When the tree looks good, we make sure the stable tree is in synch with
the tarball rolled (should be a simple diff and merge step, easy to do
with CVS), and change the values in ap_release.h, then we tag and roll the
real tarball from the stable tree.
The merge step could be done once a week, but it would have to be done
manually. It is acceptable (although strongly discouraged) to break the
httpd-2.0 build for any system. It is absolutely not allowed to break the
httpd-2.0-stable build at all. This means that the merge needs to be done
carefully.
What this also means, is that the httpd-2.0 tree is only frozen for the
ten minutes it takes to tag the tree, I only suggest that, so that CVS
doesn't get screwed up. If we know that we can tag in the middle of
somebody committing, then this freeze isn't required. The
httpd-2.0-stable tree is frozen always, but a merge from httpd-2.0 is
allowed at any time, assuming the feature is fully tested in httpd-2.0.
> [ there is an open issue for Roy to describe: what is the mechanism for
> sequencing the numbers within CVS and/or the tag/roll process; and your
> implicit question of where to record tag/roll symbols and dates ]
The above process would also solve this problem.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Release Strategy
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Feb 05, 2001 at 08:49:06AM -0500, Jim Jagielski wrote:
> Well, one major problem is that our own internal numbering system
> at present "leaks" into our official release version number...
> Tags with date stamps (APACHE_2_0_0_FEB_02_00) seem like
> good ideas, as anyone has had to deal with "now what date on
> 4-2-STABLE is OK?" knows :)
There is no "leakage" because there is no internal vs external numbering.
The next time we tag/roll, it should be called 2.0.1. The time after that,
it will be 2.0.2. etc.
Our first 2.0 "gold" release might not be until 2.0.10. That is just how it
goes.
Yes, we will go through a lot more numbers, but they're cheap :-)
The point is to get away from the notion of 2.0(alpha,beta,your-mom) type
numbering and just start zooming through the numbers. It will make the
process much easier.
Want a comparison? Did you try installing Linux kernel 2.3.1? How about
2.3.2? hehe... I didn't think so. But a number of people *did* install them
somewhere around 2.3.51 (IIRC) as that was relatively stable compared to the
rest of them.
It is very easy to just snap out a release if you don't have to apply the
brain power or restrictions of trying to determine a particular build's
status *before* the tag/roll operation. Just do it, and see what happens.
In this case, we did a tag/roll, and found it was a non-starter because of
some OS/2 breakage. Oh well. We can do it again in just a couple days. No
big overhead, no big deal.
[ there is an open issue for Roy to describe: what is the mechanism for
sequencing the numbers within CVS and/or the tag/roll process; and your
implicit question of where to record tag/roll symbols and dates ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Release Strategy
Posted by rb...@covalent.net.
> > As I said, the name was probably wrong. I do see a reason to re-tag as
> > well. The re-tag is done after updating ap_release.h. If we don't re-tag
> > after we update ap_release.h, then it will not be possible to easily
> > checkout a server that has the correct server version string. This is
> > also why I want to use the date for the tag from now on, I believe the
> > date gives more information than just a new number.
>
> Need to ask Roy on this one. I'm a bit confused about his idea here.
>
> I could see us building 2.0.5 and feeding it into the chain. Then we build
> 2.0.6. Then somebody declares that 2.0.5 can be used as a beta (i.e. we
> don't stop the testing and restart with 2.0.6). In that case, we'd need to
> branch ap_release to include any change, if it was kept in source control.
> The branch would then pick up the new tag.
>
> Note that the difference between TAG_x_y_z and TAG_BETA_n is only that one
> file. Feels a bit weird :-)
That's my problem with this too. I believe it is very important that our
builds are easily reproducable from CVS. This means that I want to see us
be able to checkout a release with a single command and be able to build
it. That is one of my goals for this process.
BTW, while we figure out how to do this well and cleanly, I am likely to
tag and roll once a day or once every other day. I see no reason to wait
until next weekend to make progress on this. If we come up with changes
to the process, I am likely to implement those changes that day, so that
people can see those changes in action, and can comment on them.
For instance, tonight, I will be retagging and rerolling the tree, with
today's date as the tag, and we will do a full roll (hopefully all
automatically). I will also move the tarball into
dev.apache.org/dist/unreleased
If there are more suggestions, I would love to hear them.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Release Strategy
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Feb 04, 2001 at 07:16:17PM -0800, rbb@covalent.net wrote:
> As I said, the name was probably wrong. I do see a reason to re-tag as
> well. The re-tag is done after updating ap_release.h. If we don't re-tag
> after we update ap_release.h, then it will not be possible to easily
> checkout a server that has the correct server version string. This is
> also why I want to use the date for the tag from now on, I believe the
> date gives more information than just a new number.
Need to ask Roy on this one. I'm a bit confused about his idea here.
I could see us building 2.0.5 and feeding it into the chain. Then we build
2.0.6. Then somebody declares that 2.0.5 can be used as a beta (i.e. we
don't stop the testing and restart with 2.0.6). In that case, we'd need to
branch ap_release to include any change, if it was kept in source control.
The branch would then pick up the new tag.
Note that the difference between TAG_x_y_z and TAG_BETA_n is only that one
file. Feels a bit weird :-)
Alternatively, ap_release.h could be generated at tag/roll or release time
(thus, not kept in source control).
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: Release Strategy
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
> As I said, the name was probably wrong. I do see a reason to re-tag as
> well. The re-tag is done after updating ap_release.h. If we don't re-tag
> after we update ap_release.h, then it will not be possible to easily
> checkout a server that has the correct server version string. This is
> also why I want to use the date for the tag from now on, I believe the
> date gives more information than just a new number.
Let's simplify this. My goal is for the quality of a release to be
determined after the tarball is made, and to stop treating minor
version changes as being significant. I would also prefer that the
build process (post-tag) be automated to the point where the RM can
say (on apache.org):
% build_httpd_release httpd-2.0 APACHE_2_0_8 beta
and have the result be a complete apache_httpd_2_0_8_beta.tar.gz.
The only place that "alpha", "beta", "gold", etc., would appear is in
the name of the tarball file and the description on our site.
It cannot appear anywhere in the source code. I do not want it to
appear in the Server version string, since that requires changing
the tarball after testing.
I don't think we need a bunch of different tags. To simplify this,
we can just stick with the current process of having the RM bump
ap_release.h before and after tagging, or simply have the RM retag
ap_release.h after bumping it. If it becomes necessary to branch
the tree in order to make minor fixes to a release, then we branch
on the version tag and merge back on the next point revision.
....Roy
Re: Release Strategy
Posted by rb...@covalent.net.
As I said, the name was probably wrong. I do see a reason to re-tag as
well. The re-tag is done after updating ap_release.h. If we don't re-tag
after we update ap_release.h, then it will not be possible to easily
checkout a server that has the correct server version string. This is
also why I want to use the date for the tag from now on, I believe the
date gives more information than just a new number.
Ryan
On Sun, 4 Feb 2001, Greg Stein wrote:
> Umm... this isn't what Roy was suggesting (as I understand it).
>
> Each release gets a new number. Done. Period.
>
> *Later* we decide to apply things like "beta candidate" or "beta" or "final"
> or whatever to that release number.
>
> The revision number is *always* bumped for a release. You've got to be able
> to tell them apart from each other.
>
> Using a new number simplifies your tag. APACHE_2_0_1, APACHE_2_0_2, etc. At
> some point in the future, we say 2.0.2 is our beta. 2.0.7 could be our
> release.
>
> There isn't really a need for further tagging when you decide something is
> alpha, beta, or release quality. You just say "2.0.3 is a development
> release," "2.0.4 is a beta", "2.0.5 is development", "2.0.6 is our second
> beta", "2.0.7 is the final release".
>
> Cheers,
> -g
>
> On Sun, Feb 04, 2001 at 05:45:53PM -0800, rbb@covalent.net wrote:
> >
> > I have begun to use the release strategy that Roy proposed. What this
> > means for the future, is that I will be tagging the tree once a weekend
> > for a long time. :-) I will tag it on the weekend, when I have time, and
> > the most I will ever ask for is a thirty minute code freeze, just long
> > enough to check out the code, and lay down the tag. If anybody else wants
> > to take responsibility for the tagging, just ask. We may be best server
> > by just having somebody run a cron job every week. Thoughts about that?
> >
> > I would like us to reach a consensus on the naming scheme we will use, and
> > how this will work going forward.
> >
> > Here is my opinion, and I would really like comments.
> >
> > 1) In release.h, we don't modify the AP_SERVER_BASEREVISION macro until
> > the tree has been accepted. Once it has been accepted, we check out the
> > tree again using the tag, modify that one file, and re-tag the tree. I
> > don't believe that will cause any problems, but CVS experts should check
> > my logic there.
> >
> > 2) For the tag names, I dislike the tag I used this week. I believe that
> > in the future, the tags should be the date in a format like:
> >
> > APACHE_2_0_Feb_04_01
> >
> > This allows us to immediately identify the version of the software we are
> > using, and know a lot about it. Most of us have a reasonable idea of what
> > the code looks like, so using dates should make it much easier for us to
> > track.
> >
> > 3) Once a tree has been accepted as being of release quality, I would
> > like to see us tag the tree with APACHE_2_0_Beta_1_STABLE or something
> > like it.
> >
> > 4) I also plan on creating a script that will live in the Apache web
> > site, which will automatically checkout a specific tag, and roll the
> > actual release. That script will be created next week sometime, and it
> > will be used to roll the first actual beta release. This will make it
> > much easier for people to do the rolling. When I create that script, it
> > is possible I will need to change the layout of some of the files, I won't
> > know until I try to create it.
> >
> > That's it. Comments? Thoughts? Critisims?
> >
> > Ryan
> > _______________________________________________________________________________
> > Ryan Bloom rbb@apache.org
> > 406 29th St.
> > San Francisco, CA 94131
> > -------------------------------------------------------------------------------
>
> --
> Greg Stein, http://www.lyra.org/
>
>
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Release Strategy
Posted by Greg Stein <gs...@lyra.org>.
Umm... this isn't what Roy was suggesting (as I understand it).
Each release gets a new number. Done. Period.
*Later* we decide to apply things like "beta candidate" or "beta" or "final"
or whatever to that release number.
The revision number is *always* bumped for a release. You've got to be able
to tell them apart from each other.
Using a new number simplifies your tag. APACHE_2_0_1, APACHE_2_0_2, etc. At
some point in the future, we say 2.0.2 is our beta. 2.0.7 could be our
release.
There isn't really a need for further tagging when you decide something is
alpha, beta, or release quality. You just say "2.0.3 is a development
release," "2.0.4 is a beta", "2.0.5 is development", "2.0.6 is our second
beta", "2.0.7 is the final release".
Cheers,
-g
On Sun, Feb 04, 2001 at 05:45:53PM -0800, rbb@covalent.net wrote:
>
> I have begun to use the release strategy that Roy proposed. What this
> means for the future, is that I will be tagging the tree once a weekend
> for a long time. :-) I will tag it on the weekend, when I have time, and
> the most I will ever ask for is a thirty minute code freeze, just long
> enough to check out the code, and lay down the tag. If anybody else wants
> to take responsibility for the tagging, just ask. We may be best server
> by just having somebody run a cron job every week. Thoughts about that?
>
> I would like us to reach a consensus on the naming scheme we will use, and
> how this will work going forward.
>
> Here is my opinion, and I would really like comments.
>
> 1) In release.h, we don't modify the AP_SERVER_BASEREVISION macro until
> the tree has been accepted. Once it has been accepted, we check out the
> tree again using the tag, modify that one file, and re-tag the tree. I
> don't believe that will cause any problems, but CVS experts should check
> my logic there.
>
> 2) For the tag names, I dislike the tag I used this week. I believe that
> in the future, the tags should be the date in a format like:
>
> APACHE_2_0_Feb_04_01
>
> This allows us to immediately identify the version of the software we are
> using, and know a lot about it. Most of us have a reasonable idea of what
> the code looks like, so using dates should make it much easier for us to
> track.
>
> 3) Once a tree has been accepted as being of release quality, I would
> like to see us tag the tree with APACHE_2_0_Beta_1_STABLE or something
> like it.
>
> 4) I also plan on creating a script that will live in the Apache web
> site, which will automatically checkout a specific tag, and roll the
> actual release. That script will be created next week sometime, and it
> will be used to roll the first actual beta release. This will make it
> much easier for people to do the rolling. When I create that script, it
> is possible I will need to change the layout of some of the files, I won't
> know until I try to create it.
>
> That's it. Comments? Thoughts? Critisims?
>
> Ryan
> _______________________________________________________________________________
> Ryan Bloom rbb@apache.org
> 406 29th St.
> San Francisco, CA 94131
> -------------------------------------------------------------------------------
--
Greg Stein, http://www.lyra.org/
Re: Release Strategy
Posted by Greg Stein <gs...@lyra.org>.
On Sun, Feb 04, 2001 at 07:10:25PM -0800, rbb@covalent.net wrote:
>
> > > We may be best server by just having somebody run a cron job every
> > > week. Thoughts about that?
> >
> > I think that's a very good idea. You might even have the cron job roll a tarball with
> > the date stamp. But at least have the tagging be done automatically. =-)
>
> The reason I didn't want the roll to be done automatically is because we
> are trying to separate the tag from the roll.
As I understood Roy (and agree with this): we tag and roll continually.
There is no separation of that step.
The characterization of the release is what changes. Every tag/roll spits
out a tarball to work with. If it is reasonably stable, then we call it an
alpha. If it is good stuff, we call it a beta. etc.
Calling it alpha, beta, whatever, comes after the tag/roll/test/whatever
process.
Cheers,
-gx
--
Greg Stein, http://www.lyra.org/
Re: Release Strategy
Posted by "Guille (Bisho)" <bi...@onirica.com>.
> > > 2) For the tag names, I dislike the tag I used this week. I believe that
> > > in the future, the tags should be the date in a format like:
> > >
> > > APACHE_2_0_Feb_04_01
> >
> > They'd sort better with numeric dates, eg APACHE_2_0_20010204.
What about APACHE_2_0_2001-02-04???
It doesn't affect to the sorting, and its more clear.
--
\|||||||/ Guillermo Pérez Pérez
< o o > - bisho@onirica.com
\ L / - bisho@eurielec.etsit.upm.es
-oOOo-------oOOo-
Onírica: Análisis, diseño e implantación de soluciones informáticas
http://www.onirica.com
Re: Release Strategy
Posted by rb...@covalent.net.
> > We may be best server by just having somebody run a cron job every
> > week. Thoughts about that?
>
> I think that's a very good idea. You might even have the cron job roll a tarball with
> the date stamp. But at least have the tagging be done automatically. =-)
The reason I didn't want the roll to be done automatically is because we
are trying to separate the tag from the roll.
> > 2) For the tag names, I dislike the tag I used this week. I believe that
> > in the future, the tags should be the date in a format like:
> >
> > APACHE_2_0_Feb_04_01
>
> They'd sort better with numeric dates, eg APACHE_2_0_20010204.
Yeah, good idea.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
Re: Release Strategy
Posted by Cliff Woolley <cl...@yahoo.com>.
--- rbb@covalent.net wrote:
> We may be best server by just having somebody run a cron job every
> week. Thoughts about that?
I think that's a very good idea. You might even have the cron job roll a tarball with
the date stamp. But at least have the tagging be done automatically. =-)
> 2) For the tag names, I dislike the tag I used this week. I believe that
> in the future, the tags should be the date in a format like:
>
> APACHE_2_0_Feb_04_01
They'd sort better with numeric dates, eg APACHE_2_0_20010204.
My $0.02...
--Cliff
__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35
a year! http://personal.mail.yahoo.com/