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 2.0.45.1 of mod_foo. But what about
> mod_bar and the other modules? Will their tags need to be bumped up to
> 2.0.45.1 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..
-alex
