Subject: Re: Topic: Versioning scheme and 1.0
From: Jesper Skov (jskov@zoftcorp.adsl.dk)
Date: Thu May 03 2001 - 02:06:05 CDT
>>>>> "rms" == rms <rms@greymalkin.yi.org> writes:
rms> On Wed, May 02, 2001 at 01:49:55PM -0700, WJCarpenter wrote:
jesper> I just wanted to have an "official" poll on my suggestion for
jesper> the alternative versioning scheme. Go read my posting on that:
jesper> http://www.abisource.com/mailinglists/abiword-dev/01/April/1264.html
jesper> But substitute the next version with 2 instead of 42 as in the
jesper> mail.
>> I agree with the proposal for simple integer release numbers.
rms> t's different in
rms> Release 43 pre 1 Release 43 pre 2 Release 43 pre 3 Release 43 pre
rms> 4 ... whatever it takes... Release 43
rms> Release 43 Build 2 Release 43 Build 3 ...
rms> ????
rms> And
rms> 0.7.X 0.7.X+n... whatever it takes... 0.8.0 (release marked as
rms> stable beta by the 0 and the even number 8) 0.8.1 (bug fix for
rms> bet 0.8)
It's different in that no-one gets itchy about a new major release
when the revision counters get to be 2-digit.
I'm not sure about this, but I think 0.7.15 suggests to many people
that we'd be going for 0.8 soonish - because we've ben with 0.7 for so
long, and so much has happened. This is not the Linux kernel with
bi-weekly releases, so we'll never get to 0.x.>20 in less than a year.
Anyway, my point is that the integer release number is open ended -
there's no implicit information in the version number about how long
we've been at any given step in AbiWord's evolution. It becomes a
sequence of interesting releases instead (other projects use +0.0.1
for mostly bugfixes IMO - we're rather different in that regard in
AbiWord).
rms> Although simpler to use, the first case ONLY shows a
rms> prograssive development. The usual numbering scheme shows
rms> progressive developement AND release status.
I'm only interested in progressive development. That's _all_ I want
to show from bumping the release number. The status is
_AbiWord_ - I've always thought it was braindead that users had to
judge application improvement from a version number. Makes sense in
the commercial world; if the cashflow is low, make a major version
bump and cash in as the users stampede. But we're not driven by
cool cash, so we can easily afford to be user friendly - by moving the
state from the version string (which everyone interprets differently
anyway) to the application.
In other words, your perception of what needs to be added to AbiWord
to make a major revision bump differs from mine, which differs from
Dom's, which differs from... You get it...
With the integer system we make a new release when we feel there's
been some nice new improvement we'd like our users to be aware of, or
if too long time has passed since last release.
Oh, and this does not change the fact that we must have a focus on
bug-lite releases. For every release, we should do at least one or two
pre-preleases with a weeks delay to get stuff tested and polished. And
something like every year, we should call a feature freeze for a month
or so to really beat down the bug counts. Make those releases
<integer>+ if you will.
Jesper
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:00 CDT