Re: Issues marked as fixed in 25.2

[Eli Zaretskii]

> From: John Wiegley <address@hidden>
> Date: Mon, 14 Nov 2016 14:00:47 -0800
> Cc: address@hidden
> 
> >>>>> "GM" == Glenn Morris <address@hidden> writes:
> 
> GM> I suggest looking at the date the issue was closed and comparing it to the
> GM> date the version numbering was changed. But then you also need to check
> GM> for issues that have been backported since. And you might also want to
> GM> review every such issue to see if it _should_ be backported now.
> 
> Btw, it's exactly this sort of confusion that I wanted to avoid by using a
> 3-branch scheme (current release target, next minor, next major).
> 
> The 2-branch scheme we have now makes this sort of confusion a regular part of
> ongoing development, because we'll always encounter the case where a fix on
> 'master' ends up becoming part of the next release, ahead of whichever version
> master was marked as at the time the bug was fixed.

I think the confusion will happen no matter which scheme we choose.  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.

I understand the rationale behind trying to record in the bug where it
is solved, but I don't think that goal is achievable in practice.