Subject: Re: Call for writers - help us with the user documentation
From: Ron Ross (ronross@colba.net)
Date: Mon Apr 30 2001 - 16:27:28 CDT
Jesper Skov <jskov@zoftcorp.adsl.dk> writes:
[...]
> Actually, I was giving half a thought to abandoning x.y.z versioning
> altogether and, where we would have gone for 0.9, go for:
>
> Release 42
>
> Then we mess around and do our stuff. When we think it's time we got a
> new release out the door, we do weekly stabilizing beta releases:
>
> Release 43 pre 1
> Release 43 pre 2
> Release 43 pre 3
> Release 43 pre 4
> ... whatever it takes...
> Release 43
>
> It's open ended, and we are bound by no established versioning
> scheme. Also, by committing to weekly releases we set ourselves
> measurable goals that should help make progress more visible for
> interested users who want to help test.
>
> If we want to fix bugs in a release, do
>
> Release 43 Build 2
> Release 43 Build 3
> ...
>
>
> But I'm not sure the world is ready for something like this :)
I'm not sure about incrementing to such high version numbers, but I like
the basic scheme proposed here. Produce a stable version, with the
current feature set, that gets incremented by minor version numbers as
bug fixes are incorporated, while continuing development on another
tree, labeled as StableVersion+1.preX, accessible to the public but with
added proviso about developmental software. This is how Linux kernel
does it, more or less, and the scheme was always clear to me, even as
"newbie". I tend to favour rms's view on being conservative in
announcing stable releases, but think it's not my place to press the
case here. However, the scheme proposed would have the benefit of making
immediately known to the user that some really crucial/nifty features
that are absent from the current stable release -- whatever the version
number -- are being actively developed.
Ron
This archive was generated by hypermail 2b25 : Mon Apr 30 2001 - 16:26:56 CDT