Re: [jerome.marant@free.fr: Re: Possible help with stable Emacs releases.]

[Rob Browning <rlb@defaultvalue.org>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Let's ignore version numbers for now.  The issue of how to number
> them seems to always drift into never ending discussions and I have
> no interest in them.  Use whichever scheme you like.
>
> Let's call 21.1 FOO, 21.2 BAR and 21.3 BAZ.
>
> FOO was a major release, BAR and BAZ were minor releases cur from a
> branch (that started off of FOO) and with only safe bugfixes
> applied.

The only problem I can see with that approach (though it might not
matter to you upstream) is that it makes the eventual version number
of the more substantial upstream development releases a moving target.

Imagine that 21.4 has been relased, and then imagine Jerome and I have
made 21.5, 21.6, and 21.7 bugfix releases using backports or patches
that were submitted to Debian, that have been approved by the Emacs
developers.  Now imagine that you're preparing to make a new release
from the "main" upstream development branch.  What do you call it?  If
you pick 21.8 and then you're unexpectedly delayed for a month or two
(for whatever reason), then we're in trouble if we need to make a
bugfix release (imagine a data-destroying bug of some kind that can't
wait).  We'd need something between 21.7 and 21.8.

Of course if you don't the possibility that you might have to keep
changing the pending upstream release number whenever we make a minor
bigfix release, then there's no problem, but even so, I suspect
there's also some value in people being able to easily tell the
difference between a truly minor bugfix release and one that's been
worked on for (historically) on the order of a year.

So while I don't have any special attachment to the X.Y.Z numbering
scheme, it's at least one way to fix both those problems.

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4