httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <>
Subject Re: 2.0.28-beta release?
Date Tue, 13 Nov 2001 20:32:00 GMT
On Tuesday 13 November 2001 12:21 pm, William A. Rowe, Jr. wrote:
> From: "Ryan Bloom" <>
> Sent: Tuesday, November 13, 2001 2:00 PM
> > On Tuesday 13 November 2001 11:28 am, William A. Rowe, Jr. wrote:
> > > I'd suggest that you checkout on APACHE-2_0_28, tag as
> > > APACHE-2_0_28_ALPHA for historical reasons, then we can add
> > > APACHE-2_0_28_BETA, etc.
> >
> > No, there is 2.0.28, period.  There isn't a 2.0.28-alpha and 2.0.28-beta
> > code base.  There is one 2.0.28 codebase.  You could have different
> > versions if the alpha/beta distinction was in the code, but it isn't.  It
> > is only in the tarball name.
> Exactly my the point in the following sentence, which you snipped;
> > > BTW - 1.3 had this great little minor rev field that always started at
> > > 100. Shame that's gone.
> I believe you eliminated this designator, no?
> I agree, no code twists after alpha tag until we get a decent versioning
> schema back.
> We know this one isn't GA quality (a much better beta, but no GA.)  So it's
> pointless to fight over bitty fixes once we rolled the alpha tarball.

Yeah, we had that field, but we didn't do ANYTHING with it.  Grep the entire
code base.  The only place that macro is used is in the definition.

We have a decent versioning scheme.  We have three version numbers,
Major, minor, and patch.  Once a release is made, the code for that release
cannot be changed.  Changing the code after a release is too confusing, because
it is almost impossible to keep track of which version you are using.  If the release
isn't ready to be released, then you go to the next version.

Our problem, is that we have a bunch of perfectionists on this project.  :-)
A beta doesn't need to be rock-solid, it just needs to be better than the last
beta.  We could have released over 10 betas by now, but one thing or
another always makes us stop the release.  If we would roll releases, and get
them into people's hands, the versioning scheme would work just fine.  The
problem we are having, is that when we go to make a release, we are
incredibly concerned that there might be one small bug in it, so we keep
making changes after the tag was laid.  This gets us right back to the problem
we were having in 1.3, where people are commiting code that hasn't been
well tested, and we are releasing it.


Ryan Bloom
Covalent Technologies

View raw message