[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: No calc in pretest?

From: Kim F. Storm
Subject: Re: No calc in pretest?
Date: 02 Jul 2002 10:49:34 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

Francesco Potorti` <address@hidden> writes:

> Jon Cast <address@hidden> writes:
>    Is there any chance y'all could be persuaded to number releases in a
>    way that'll make it obvious what's a bug fix and what's a release
>    from CVS head?  (I.e.,
>    21.4    -- Release from CVS
>    21.4.1  -- Bug-fix
>    21.4.2  -- Bug-fix
>    21.4.50 -- CVS
>    21.5    -- Release from CVS
> I agree that this scheme or any other clear numbering scheme should be
> adopted to distinguish bug-fix only releases.

This could also help us avoid the current hazzle of modifying the
"next version" number whenever we need to make a bug-fix release.  So
far, we have had to change the "expected" number from 21.3 to 21.4
which has an impact not only on documentation, but also on the
:version tags we put on customize options.

Alternatively, we could adapt the linux numbering where odd-minor are
development versions and even-minor are releases, e.g.

        22.1.1  -- CVS development version for 22.2
        22.1.90 -- pretest for 22.2

        22.2.1 -- initial release
        22.2.2 -- bug-fix

        22.3.1 -- CVS development version for 22.4
        22.3.90 -- pretest

        22.4.1 -- release

I switched to 22.x since introducing a new numbering scheme in the
middle of an existing non-conforming numbering scheme (as 21.x)
doesn't make sense...

Also, the number of changes since 21.1/2/3 seems to be fairly
large, so maybe it does make sense to switch to 22.x for the
next release from CVS.

The justification could be that 22.2 would be the first major release
since opening the emacs development to a broader group of developers.

The suggested numbering scheme would also allow us to make development
snapshots like 22.1.1, 22.1.2, 22.1.3 etc. to be announced on the
pretesters list for interrim feedback during development for those
interested.  [I'm not implying that we _should_ do this, just that we
_can_ do it].

Kim F. Storm <address@hidden> http://www.cua.dk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]