httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Stewart <>
Subject Re: Q1: Rollup Release Format - Score So Far...
Date Thu, 20 Sep 2001 12:31:52 GMT
Graham Leggett wrote:

> Alex Stewart wrote:
>>There seems to be a big assumption here that "release" is the same as
>>"version", which seems like an unnecessary restriction.
>>Frankly, if these are separate subprojects we're talking about (which it
>>seems pretty clear they're going to be evolving into, if they aren't
>>already), they should have separate, independent versioning.
> But consensus has just been reached that there will be a single rollup
> release, so out of necessity there will have to be one version per
> release.

Why?  It's the necessity for the one-to-one mapping between versions and 
releases that I'm questioning.  I don't see the requirement.  My point 
is that there is (and should be) a difference between _release_ 
numbering and _version_ numbering.  The same version of a module may go 
in multiple releases (if nothing's changed in that particular bit), so 
why change the module's version number just because it's being packaged 
again?  Likewise, why restrict module versioning such that its version 
can't change unless there's another rollup (or worse yet, its version 
can't change unless there's a new httpd released)?

>>Trying to
>>coordinate the version numbers of umpteen different projects just
>>because one of their possible distribution channels distributes them
>>together is silly and a lot of unnecessary extra work.
> We are currently coordinating three different projects (httpd-core, apr,
> apr-util) being released together and things are working fine. I don't
> see how expanding this to 4 or 5 is such a problem?

Well, your previous message demonstrated one reason:  It requires a lot 
more coordination (the "enormous trumpet call") to make sure things are 
consistent at rollup time, and there's no advantage (that I see) gained 
from it.  It also doesn't scale well at all.  (As somebody who's 
designed and administrated a few different large-scale CVS-based 
software release systems, I'm speaking from personal experience on that 

In the short term, we may not be scaling to more than 4 or 5 projects, 
but I don't see why we should deliberately limit ourselves to that 
either, particularly since there's the potential for splitting this 
whole thing out into quite a few more groups (or bringing more things 
into the fold) later on if people decide it's worth it.

>>I agree with the global tagging thing, but I don't see why this much
>>effort has to be put into making everything ready concurrently just so
>>it can be rolled together.  Automatic coordination of this sort of thing
>>is part of what CVS (and in particular CVS tags) is supposed to be good for.
> "Making everything ready" just means "make sure it's not currently
> broken". This is exactly how we do things now, I don't think anything
> should change.

Except that you're going to get multiple semi-independent groups working 
on multiple internal timelines and all of a sudden you have to hold off 
the release of module A because module B's got a big problem that'll 
take a few days to fix, then by the time module B is fixed, module C has 
a problem, and when everything finally gets straightened out, something 
you could have gotten out the door in an hour has taken a week and a half.

>>It seems to me that each subproject should attempt to maintain at all
>>times a tag that says "current rollup-candidate", which isn't
>>necessarily the latest-and-greatest, but is the latest version that's
>>stable and without showstoppers.

[Actually, I should have said "it's a _recent_ version that's stable and 
without showstoppers".]

> I suggested this a while back - but after thinking about it some more I
> realised this just means extra work. Instead of tagging it once when the
> trumpet call is released, we must now update the latest-known-working
> tag every time we make a commit - yuck.

Umm, no.  All it means is that each group maintains its own release 
schedule, and updates its "releasable" tag appropriately for their 
schedule.  This doesn't have to be every commit, it could be every day, 
or every week, or whenever somebody feels like it (and it _can_ be that 
flexible, because each group doesn't have to drop everything and 
coordinate with everybody each time somebody wants to update things).


View raw message