On Sun, 2003-12-14 at 01:03, kfogel@collab.net wrote:
> 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?
Initially I thought we wouldn't want to make any more releases from the
trunk at all; we'd make semi-frequent bugfix releases to the most recent
stable branch, and we'd infrequently branch for a new stable release,
and that would be it. But gstein disagreed, claiming that we'd want to
make trunk releases on a frequent basis, leading to the "svn-snapshot"
proposal. Having received disagreement on this point, I assumed that we
wanted a version numbering system that was permissive of both trunk and
branch releases at any time.
> 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 :-).
Okay. I'll try to set some parameters, starting with what I think we
can all mostly agree on:
* We will have stable releases. The first one will be called 1.0 or
1.0.0. Releases leading up to 1.0 will be called 0.36, 0.37, etc..
* We will branch for some short period (4-8 weeks, perhaps) before
each stable release, to promote the stability of the release.
* During the period leading up to a stable release, we will release
tarballs from the branch for testing.
* During the period leading up to a stable release, we will NOT
release tarballs from the trunk, even if we have some cool new
feature there we want tested.
* It is important that non-stable releases are somehow labelled as
such. (Not 100% consensus here.)
Here's some points of contention:
* Between stable releases, we will {frequently/infrequently/never}
make unstable tarballs based on the trunk, with no expectation that
they would ever lead to a stable release.
* If we do make these unstable tarballs, we {would branch for a week
or so first, like we do with 0.x releases now, in order to write a
CHANGES file and catch serious bugs/would just document the really
interesting new features and then make a snapshot of the trunk,
because we won't have a population of users trying to use our
unstable trunk releases for serious work like we do for 0.x
releases}.
* If we do make these unstable tarballs, it is {good/bad} for them to
have similar-looking version numbers to testing versions leading up
to the next stable release. (Note that both Linux and GNOME,
the two most visible users of the odd/even convention, have warped
their version numbering so that testing releases look different from
trunk unstable releases. Linux is currently sitting at
2.6.0-test11,
and GNOME has been known to bump the last number to 90 or 100 in
order to indicate proximity to a coming even release.)
* We should {expect binary packagers to make .debs and .rpms of
unstable and/or testing releases, and try to help them/discourage
them from making .debs and .rpms of unstable and/or testing releases
and not worry if their lives become difficult if they do so}.
* We should {decide on our version numbering scheme based on first
principles/try to {roughly/strictly} emulate
{Linux/GNOME/BDB/Mozilla/*BSD/something else}}.
Karl's proposal (odd/even, with an "unstable" prefix on odd) is
compatible with having unstable trunk tarballs, is compatible with
branching for a week before unstable trunk tarballs, and puts unstable
trunk tarballs in the same version line as stable release testing
tarballs. Binary packages of unstable or testing tarballs could be made
using the same package name as the stable releases, and the version
numbering works out (a stable release supercedes period unstable
releases and is superceded by subsequent unstable releases). It roughly
resembles the Linux or GNOME schemes.
My proposal (no odd/even, unstable trunk releases prefixed by "snapshot"
and identified only by trunk revision number, testing releases prefixed
by "beta" and identified by X.Y branch and revision number) is
compatible with having unstable trunk tarballs, is not very compatible
with branching for a week before unstable trunk tarballs, and puts
unstable trunk tarballs in a different version line from stable release
testing tarballs. Binary packages of unstable or testing tarballs would
have to use different package names from stable releases, with conflict
markers so people can't install both at once. It roughly resembles KDE
or Mozilla or *BSD, though those projects almost always muck with the
version number rather than the prefix to indicate trunk-unstable or
release-testing tarballs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 14 18:19:15 2003