[Top][All Lists]

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

2.18 release plans (again).

From: David Kastrup
Subject: 2.18 release plans (again).
Date: Tue, 22 Oct 2013 20:06:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

Ok, after looking at the current situation and the current patches in
review/countdown, I've decided that I'll fork off the stable release
branch 2.18 after the current batch in countdown is in master.  After
that point of time, I'll only cherry-pick patches into the stable branch
after having convinces myself that they are no trouble.

What does this imply for other branches?

a) master branch

The master branch should not receive merge nuisances.  Those are, for
example, large reformattings and other cosmetic changes.  Also code
refactoring with non-trivial extent should be postponed.  No syntax
changes requiring convert-ly rules should be performed since we want to
be able to release multiple 2.17 releases while 2.18.0 has not yet been
released, without messing up the order of convert-ly changes.
Documentation changes should restrict themselves to corrections, and
those should be done _fast_ so that translators have a chance to catch

b) translation branch

The translation branch will stop getting merged with master.  Some
documentation changes from master might get cherry-picked into
translation (I will do that myself), and translation will get merged
into the stable branch periodically, also by myself.  Translators are
urged to start bringing the translation branch into releasable state
_now_.  There will only be few changes from now on until the release of

We might get one or two unstable releases before 2.18 gets out.
Personally, I'd prefer if they used numbering starting with 2.17.95 to
make it very clear to people that we are in the final stages of shaping
2.18 up and that any release-relevant testing, reports, and fixes have
to come in _fast_.

David Kastrup

reply via email to

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