plan for branching

[Jonas Hahnfeld]

With the localization issues hopefully resolved and no objecting
comments to the last thread, I think we should go ahead and create
stable/2.22, with release candidates (2.21.8x) on the road to 2.22.0.

After creating the branch, I will (unless somebody doesn't want me to
do this and volunteers to do the work; see also below):
 - bump master to 2.23.0, in preparation for the next cycle;
 - bump stable/2.22 to 2.21.80, in preparation for the first release
candidate;
 - merge and / or forward the translation branch to stable/2.22.

As a result,
 - release candidates are cut from stable/2.22;
 - master is open again for feature development etc., eventually
released as 2.23.0 after 2.22.0 is done (note that it would be helpful
to avoid large-scale changes that complicate the following points);
 - fixes are developed, reviewed, and merged to master via the usual
countdown cycle and cherry-picked into stable/2.22 once landed;
 - the same goes for the English documentation, which may be cherry-
picked into stable/2.22 if applicable;
 - in contrast, translation targets the stable/2.22 branch to restrict
the documentation to what's in there; I will try to cherry-pick those
commits to master to avoid a similar situation we had after 2.20.

Thoughts? Something I forgot?

Jonas

signature.asc
Description: This is a digitally signed message part