RE: Issues marked as fixed in 25.2

[Herring, Davis]

> I think the idea that we can know which version will come from what
> branch is a fallacy, because the original intent can always be
> thwarted by later decisions, based on situations no one can predict.

That's why the three branches should not literally be "(current release target, 
next minor, next major)".  For a library equipped with an soname, the standard 
versioning system suggests (bug fixes, new features, incompatible changes).  
The same idea can be applied to a gradually evolving editor: commits are not 
assigned to a supposedly certain destiny, but rather are sorted according to 
the probability that they might delay a release.

Then, whenever a "minimal changes" release is desired (e.g., to fix a 
vulnerability without breaking other things), it can be made immediately from 
the strictest branch.  When work on a major feature drags on, meaningful 
releases can be made without it by releasing from the middle branch.  (These 
two use cases are the reason for the number of branches being 3; the match with 
libraries is largely coincidental.)  When instead release day comes for the 
middle branch before the strict branch, you just merge the latter into the 
former first.

There are two refinements to make.  First, the "strictness" of a branch has two 
interpretations: either in terms of the user-visible behavior changes, or in 
terms of the (possibly destabilizing) code changes.  The former is more 
appropriate for the library case, because feature lists and 
backwards-compatibility guarantees are defined in terms of the visible 
behavior.  It also has the advantage of tending to reduce merge conflicts and 
cherrypicking, because refactoring can be done on the bugfix branch even if it 
is to support new features to be added elsewhere.  The latter interpretation 
may however be more appropriate for Emacs, where no absolute definition of 
compatibility exists but stability is very important.

The second refinement is just (the bikeshedding of) what to call such branches 
for Emacs, with a mind to making it easy for committers to categorize commits.  
The schema that seems most obvious to me is (bug fixes and documentation work, 
well-separable features, core features) which maps well to the past "major 
version features" (like lexical binding and modules).  The first two are often 
distinguished by whether a change includes NEWS text.

Finally, you can still have feature branches, as we already do; this scheme 
just reduces the anxiety associated with the merge of such a branch by allowing 
it to remain targeted at an unspecified release.

Davis