> The problem comes when we branch for the next stable release (1.2, in
> your proposal). Now we have to differentiate between beta releases of
> 1.2 and unstable releases on the trunk which happen to chronologically
> predate the release of 1.2. The even/odd scheme works against us; we
> could wind up with confusing release orders like:
>
> subversion-unstable-1.1.1
> subversion-unstable-1.1.2
> <branch point for 1.2>
> subversion-unstable-1.1.3 from branch
> subversion-unstable-1.3.0 from trunk
> subversion-unstable-1.1.4 from branch
> subversion-unstable-1.3.1 from trunk
> subversion-1.2.0 from branch
>
> By using odd/even, you are trying to linearize a fundamentally
> non-linear structure of releases, and the result is confusion. This is
> why Linux winds up with version numbers like 1.2.0-pre6 even though it
> uses odd/even.
Aha, there's a communications gap here. My assumption, which I should
have made explicit, is that we don't release from two different dev
lines simultaneously.
That is, we wouldn't be trying to stabilize 1.2 (via the unstables or
"betas" leading up to it) while at the same time making releases from
trunk. There just wouldn't be trunk snapshots. We don't do them now,
after all; is there a reason to start?
I was only trying to linearize a linear release structure. If we're
going to have a non-linear structure, then my proposal won't work :-).
The only time we'd have releases coming from two different lines would
be when we're releasing unstables (leading to a new stable release),
while simultaneously making a bugfix release from an existing stable
line. But bugfix releases are a different kind of beast: we just
branch the old release tag, apply the fix, test the heck out of it,
and release. The idea is that only very conservative changes go into
a bugfix release of a stable line anyway.
> So, let me counterpropose:
>
> Stable releases are named subversion-x.y.z, no odd/even
> Not-yet-vetted branch releases are named subversion-beta-x.y-rXXXXX
> (or subversion-alpha-x.y-rXXXXX if we feel they're of alpha quality)
> Snapshots off the trunk are named subversion-snapshot-rXXXXX
> We discourage binary packaging of anything other than stable releases
If we want all these kinds of releases going on simultaneously, a
system like this could work. But I don't think we want that
situation. Instead, let's try to concentrate on one line at a time,
and deviate from that only when a serious bug in a stable release
demands it.
I won't comment on the specifics of the counterproposal right now.
It's clear we need to first figure out the semantics of our release
structure, before we can agree on a syntax!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 14 07:51:40 2003