emacs-devel
[Top][All Lists]
Advanced

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

Re: Updating release version to 22.1


From: David Kastrup
Subject: Re: Updating release version to 22.1
Date: Wed, 09 Feb 2005 01:32:11 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

address@hidden (Kim F. Storm) writes:

> Miles Bader <address@hidden> writes:
>
>> On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <address@hidden> wrote:
>>> What's the rational for not using 22.0.x for development versions?
>>> It would be so much simpler ...
>
> Because it - IMO - is confusing.
>
> Right now (or two days ago) we had released 21.3 and were working on
> the trunk towards a release 21.4.
>
> But the version on the trunk is numbered 21.3.50
>
> Typically, the user who built 21.3 has a version called 21.3.1 or
> 21.3.2 which is pretty close to 21.3.50

Ok, I forgot about _build_ numbers.  Doing a quick locate, I find

    /usr/local/emacs-21/share/emacs/21.3.50/etc/DOC-21.3.50.30
    /usr/local/emacs-21/share/emacs/21.3.50/etc/DOC-21.3.50.31
    /usr/local/emacs-21/share/emacs/21.3.50/etc/DOC-21.3.50.32

Maybe _build_ numbers should be tagged off with -%d instead of .%d
after all.  Yes, this is the same numbering scheme that RPMs and other
packages tend to use, but they use it for _exactly_ that purpose: to
indicate build numbers (and it does not usually get reflected in an
file names within the package).

> But if we could agree that we always release major versions from the
> trunk and each major release gets a new major number 22.1, 23.1,
> etc, I see no problem using 22.0.0, 23.0.0, etc as development
> versions, ans 22.0.1, 22.0.2, etc for the pretests.
>
> Bug fixes would be released from branches, and be named 22.2, 22.3,
> etc.
>
> Looking at past history, this wont cause major number inflation --
> if lucky, we will release 30.1 in 2030 which isn't too bad :-)
>
> That is indeed a simple scheme which I would support.
>
> So Richard, if we could agree that major releasees from the trunk
> always gets a new major number, we will get a simple numbering
> scheme without the risk of accidentally using a "reserved" release
> number as you just did.
>
> It would be MUCH LESS HASSLE for future work if we implemented this
> scheme right away.

Seconded.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum




reply via email to

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