From: David Kastrup <dak@gnu.org>
Cc: miles@gnu.org, rms@gnu.org, "Jérôme Marant" <jmarant@free.fr>,
emacs-devel@gnu.org
Subject: Re: Updating release version to 22.1
Date: Wed, 09 Feb 2005 01:32:11 +0100 [thread overview]
Message-ID: <x54qgmd14k.fsf@lola.goethe.zz> (raw)
In-Reply-To: <m38y5ytwmd.fsf@kfs-l.imdomain.dk> (Kim F. Storm's message of "Wed, 09 Feb 2005 01:17:30 +0100")
storm@cua.dk (Kim F. Storm) writes:
> Miles Bader <snogglethorpe@gmail.com> writes:
>
>> On Tue, 08 Feb 2005 22:18:41 +0100, Jérôme Marant <jmarant@freefr> 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
next prev parent reply other threads:[~2005-02-09 0:32 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-08 13:06 Updating release version to 22.1 Kim F. Storm
2005-02-08 13:34 ` David Kastrup
2005-02-08 14:46 ` Stefan Monnier
2005-02-08 15:05 ` Kim F. Storm
2005-02-08 15:43 ` Han Boetes
2005-02-08 16:24 ` David Kastrup
2005-02-08 15:58 ` David Kastrup
2005-02-08 20:12 ` Kim F. Storm
2005-02-08 21:18 ` Jérôme Marant
2005-02-08 22:34 ` David Kastrup
2005-02-08 22:38 ` Miles Bader
2005-02-09 0:17 ` Kim F. Storm
2005-02-09 0:32 ` David Kastrup [this message]
2005-02-09 1:21 ` Miles Bader
2005-02-09 8:30 ` Kim F. Storm
2005-02-09 8:41 ` Miles Bader
2005-02-09 11:23 ` Kim F. Storm
2005-02-09 13:32 ` Robert J. Chassell
2005-02-09 13:59 ` David Kastrup
2005-02-09 14:15 ` Jason Rumney
2005-02-10 18:39 ` Richard Stallman
2005-02-10 21:49 ` Kim F. Storm
2005-02-10 22:33 ` Jérôme Marant
2005-02-10 22:52 ` David Kastrup
2005-02-09 14:21 ` Lennart Borgman
2005-02-09 14:56 ` Kim F. Storm
2005-02-09 9:44 ` Lute Kamstra
2005-02-09 10:54 ` Kim F. Storm
2005-02-09 10:45 ` David Kastrup
2005-02-09 10:52 ` Miles Bader
2005-02-09 11:33 ` Kim F. Storm
2005-02-10 6:01 ` Richard Stallman
2005-02-09 16:08 ` DONE: " Kim F. Storm
2005-02-09 16:32 ` David Kastrup
2005-02-09 17:39 ` Rob Browning
2005-02-10 6:01 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=x54qgmd14k.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=jmarant@free.fr \
--cc=miles@gnu.org \
--cc=rms@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.