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
bit.)
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).
-alex
