Re: Issues marked as fixed in 25.2

[Eli Zaretskii]

> From: "Herring, Davis" <address@hidden>
> CC: "address@hidden" <address@hidden>, "address@hidden" <address@hidden>
> Date: Tue, 15 Nov 2016 06:25:00 +0000
>
> > 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.

That's a different discussion, isn't it?  The issue at hand is whether
marking bugs at closure time as being "fixed in version X.Y" is
something that can avoid the danger of having the specified version be
eventually released without the fix, while the fix is actually
available with some other released version.

I submit that we cannot know in advance whether a given commit will
end up in a specific released version.  There are just too many
factors that are unknown when the bug is resolved which could easily
change the version in which the bug will be eventually fixed.  Some of
these factors:

  . a fix is found to be too dangerous for its branch, and is moved to
    another branch
  . a fix is found to be a "band-aid" type, and the real fix is on
    another branch
  . we decide to change the branch configuration

And these are only the ones I came up with within the first 5 sec of
thought.

I don't see how _any_ branch configuration could prevent the above
factors from thwarting our release plans as known when the bug is
closed and marked as fixed in some specific version of Emacs.