Trying to follow "Preparing a new major release" instructions

[Johannes Pfau]

Am Mon, 11 Feb 2013 10:14:47 +0100
schrieb "deadalnix" <deadalnix at gmail.com>:

> On Monday, 11 February 2013 at 08:54:53 UTC, Johannes Pfau wrote:
> >> To me a regression is a bug that exist in version N+1 but 
> >> doesn't in version N.
> >
> > The definition in the wiki is supposed to say exactly that. If 
> > it's
> > still unclear feel free to fix the definition.
> >
> 
> I try to understand the whole thing. If a bug exists in N+1, but 
> not in N, why does the process say that it should be fixed in N 
> and N+1 ? It make no sense.

Where did you get that impression? We should really fix that part of
the wiki page.

5.2.5 says "The regression fix must be pushed to the oldest, still
supported version branch _affected_ by the regression."

As an extreme example:
N:   2.062 worked
N+1: 2.063 regression introduced
N+2: 2.064 still not fixed
N+3: 2.065 still not fixed

Then it should be fixed in N+1, N+2, N+3, staging and master. But it
should only be fixed in releases which are still supported. As that
wiki page proposes to support only one release, only N+3, staging and
master would receive the fix.

> 
> > That's why I chose to only allow regression fixes: Regressions 
> > are
> > the most annoying bugs and often the only reason why people 
> > want a
> > minor release at all. For example:
> >
> > 2.061 works
> > 2.062 introduces a new bug #1.
> >
> > so #1 exists in 2.062 but not in 2.061 which exactly matches 
> > your
> > definition. Now everyone affected by #1 can't upgrade to 2.062.
> > Therefore #1 should be fixed in 2.062.1, 2.062.2 or some other 
> > minor
> > release. I don't know why this wouldn't make sense.
> 
> OK understood. This seem over restrictive to me, as stuff like 
> ICE in the backend or wrong codegen deserve also such fix. 
> Basically anything that don't change the language.

And that's why I said it's a judgement call. A wrong codegen fix can
also introduce new bugs. How likely it is to introduce new bugs
depends on the actual fix. In the end someone has to weigh the risk of
introducing new bugs and the use of that bug fix. Maybe it's possible
to add some more rules which come up when using the release process
though.