Future release schedules (was: make change-history on non-master branches)

[John Wiegley <jwiegley@gmail.com>]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Alas, it's not just the pretest, it's the entire life time of the release
> branch. That life time is just starting for the emacs-25 branch; I'm quite
> certain that at lease Emacs 25.2 and probably also 25.3 will be delivered
> from that branch. That's another 2 years. I don't think we want to wait that
> long for your useful corrections and general loving care of ChangeLog.2 ;-)
>
> I hope we will find a better solution to this.

Once 25.1 is out -- and this could take up to six months -- I'd like us to
switch to a different process for point releases: A new .x release every two
months, with whatever bug fixes have been accomplished in that interim.

Once the emacs-25 branch is stable, say at 25.2, primary development would
resume on master towards emacs-26. However, bugs will continue to be fixed and
back-ported to emacs-25, with regular point releases from that branch, until
it's stable enough to no longer need our attention. Beyond that point, it
becomes a frozen branch -- unless a critical bug fix occurs justifying a point
release solely for that fix.

This requires a two-pronged approach: Attention to bugs on emacs-25, and
attention to new features coming into master from patches and feature
branches. This should allow us to maintain a faster turn-around time on bug
fix releases, while not holding up integration of new feature work towards the
next major release.

The intention here is to maximize the utility of Git, now that we have it, and
to make use of its branching, merging and cherry-picking capabilities to
accelerate development, without sacrificing attention to stability for the
current "release series". I like that we have gitmerge.el, for example; I hope
we can adapt our release process to take full advantage of it.

John