emacs-devel
[Top][All Lists]
Advanced

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

Re: Next release from master


From: Glenn Morris
Subject: Re: Next release from master
Date: Thu, 21 Jan 2016 12:35:15 -0500
User-agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)

Stefan Monnier wrote:

> IOW the next release form master should be called 26.1 and 25.N should
> be kept for a bugfix-only releases from the emacs-25 branch.
>
> It's not tremendously important, but the way we've done it in the past
> ended up with all kinds of minor inconveniences when we suddenly decide
> that we need another bugfix release: e.g. having to update all
> "make-obsolete" calls, not to mention all the "will be fixed in (or
> added to) Emacs-NN.MM" already posted in debbugs, mailing-lists,
> stackoverflow, forums, and newsgroups which suddenly become lies.

FWIW, I just want to echo the above (which reiterates the policy from
https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00872.html ,
which was accepted without much debate at the time).

In master, bugs are already being marked as fixed in 25.2, items as
changed in 25.2, etc. If after 25.1 is released, an unexpected rapid
bug-fix 25.2 release is needed from the emacs-25 branch, those
references have to be changed (where possible; obviously references
outside Emacs won't be changeable). The longer master claims to be the
precursor to 25.2, rather than 26.1, the more inconvenient this becomes.

Version numbers need to be expandable (to allow for unexpected bug-fix
releases) and predictable (to avoid having to change references to the
number). The major.minor scheme, where major is bumped every non-bugfix
release, allows for that.

This means that if all goes as planned: 26.1 might not contain any
"major" new features, and 25.2 will never exist. (Unless someone wants
to maintain a bug-fix release branch, but that's a separate topic. This
scheme allows for it, whereas the old one didn't. This scheme probably
also allows for more frequent releases, which is something people have
asked for, since an extra maintenance release can be made at any time
without disruption.) This might take a little bit of getting used to,
but eg the Linux kernel, Firefox, etc, have all stopped being so
conservative with version numbers.


Long story short: if agreed, please renumber master to 26.0.50 asap.




reply via email to

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