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 08:46:35 GMT
Graham Leggett wrote:

> mod_foo wants to make a release, so they release v2.0.45.1 of the rollup
> tree, containing 2.0.45 of core and of mod_foo. But what about
> mod_bar and the other modules? Will their tags need to be bumped up to

> also? I would imagine they would, which is a problem.

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.  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.  At the same 
time, saying that we can't have a specific bundle release number because 
all the contents have different versions is equally silly.  The bundle 
release number reflects the number of the bundle, not necessarily the 
version of any of the contents.

Well, ok, it makes sense that the rollup bundle of "httpd and friends" 
should reflect the version number of the httpd core that's in it (that's 
the one version number that most people on the outside would probably 
expect to be consistent).  It also makes sense that there may be 
incremental bundles released between httpd version changes, so a 
sub-release identifier of some sort is needed.  The number on the 
bundle, however, in no way has to have any relationship to any of the 
extra module version numbers:

For example, apache-httpd-complete-2.0.1-12.tar.gz might contain:
   httpd version 2.0.1 (obviously)
   mod_foo version 2.0.1
   mod_bar version 1.7
   mod_baz version 18.7.3

apache-httpd-complete-2.0.1-13.tar.gz could contain exactly the same 
thing, except mod_bar is now at version 1.8, or whatever.

Now, admittedly, you could do the same thing with a date stamp instead 
of a revision number, but for these purposes "12" works just as well as 
"20020423", and is arguably more readable/usable (for one thing, you can 
tell that "13" is the next release after "12", but who knows what 
"20020611" is).  Anyway, the filenames we're looking at using are 
getting long enough already, IMO.

> Ideally the rollup release should commence with an enormous trumpet
> call, followed by the tagging of *all* the modules (including core) with
> the same tag. At this point *all* modules (including core) have to fix
> any showstoppers, and a release follows shortly afterwards to testers.
> If the release works, woohoo - it's a release. If not, oh well, it's an
> alpha.

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.

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.  At any point in time (any day of any 
week) and with no special warning, somebody should ideally be able to 
pull from all the appropriate CVS sources using that tag and get 
something that's appropriate to be made into a rollup tarball.  When a 
subproject has an update worthy of a new rollup, they tag it with that 
tag in their tree, and ask whoever's in charge of rolling releases to do 
another run.  At that point, a general notice might go out just so that 
everyone can do a quick double-check that what's tagged in their 
repositories is the stuff they really want going out, and then it gets 
pulled and rolled.  No big fanfare or mad scrambling needed, though.

Anyway, that's my $.02..


View raw message