unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: storm@cua.dk (Kim F. Storm)
Cc: emacs-devel@gnu.org, rms@gnu.org,
	"Jérôme Marant" <jmarant@free.fr>,
	miles@gnu.org
Subject: Re: Updating release version to 22.1
Date: Wed, 09 Feb 2005 12:23:08 +0100	[thread overview]
Message-ID: <m3d5vax9ib.fsf@kfs-l.imdomain.dk> (raw)
In-Reply-To: <fc339e4a050209004179cead71@mail.gmail.com> (Miles Bader's message of "Wed, 9 Feb 2005 17:41:37 +0900")

Miles Bader <snogglethorpe@gmail.com> writes:

>> I don't want us to get into that mess again -- so I want a scheme
>> where the next release number is _fixed_ from the start.
>
> I have no idea what you're talking about.

Which part of the sentense is difficult to understand?

>
> The problems caused by the current "mess" (21.4 released to mean
> something else, 22.1 chosen for next release) would have happened
> regardless of what scheme was chosen (including all of your wacky
> ones),

Stefan suggested 2.5 years ago to name the trunk version 22.1.

Your response was:

> From: Miles Bader <miles@gnu.org>
> In-Reply-To: <200207021509.g62F9l617691@rum.cs.yale.edu>
> Message-ID: <87n0taupfw.fsf@tc-1-100.kawasaki.gol.ne.jp>
> Date: 03 Jul 2002 00:20:19 +0900
>  
> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > We could simply decide that RC versions will be 21.1, 21.2, 21.3, 21.4
> > and the next trunk version will be 22.1 (at which point it will be on its
> > own branch for 22.2, 22.3, 22.4, ...).
>  
> No, that would be silly.  Emacs has a good history of changes in the
> major version number really meaning that major changes were made; we
> shouldn't screw that up unless it's for a very good reason (and I
> haven't seen one presented yet).
>  
> -Miles

Silly?  


>        because what occured is that an extra real release was added in
> between the last real release and the designated next real release.

Some of us saw it coming -- and you called us silly.

And now I'm called wacky.  Nice vocabulary, Miles.

> No amount of futzing around with pre-release names would have changed
> that.

True -- that's not the main issue.  

If you read my mail carefully, I'm discussing two issues:

- preventing the current mess (always use MM.1 for trunk releases
  and MM.N (N > 1) for bug fixes from the RC_MM branch -- as
  Stefan wisely suggested back then.

- finding a scheme for development and pretest naming that
  uses MM.1-something rather than _a completely different_ version
  number which MM.0-something is IMO.


> The questions, as I understand it, are merely (1) how to call real
> releases, and (2) how to call pre-releases.

That's what I'm talking about!

>
> For the next release at least, it's been decided that (1) will be
> "22.1"; what I understand Jérôme to have meant is that (2) in this
> case should be "22.0.x", where x = 1, 2, 3, ...

_IF_ we stick to 22.0-something for dev and pretest, I definitely
prefer if we keep the current scheme of 22.0.50 and 22.0.90...
rather than inventing something new.

As I said, I'll use 22.0.50 when I change things later today.

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

  reply	other threads:[~2005-02-09 11:23 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
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 [this message]
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=m3d5vax9ib.fsf@kfs-l.imdomain.dk \
    --to=storm@cua.dk \
    --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).