unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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

  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).