On Monday, 11 February 2013 at 08:59:12 UTC, Johannes Pfau wrote:
> Am Mon, 11 Feb 2013 07:03:07 +0100
> schrieb "deadalnix" <deadalnix@gmail.com>:
>
>> It seemed fixed in previous state of master, so either the tag is wrong or we have a regression. What is the state of 2.062-b1 ?
>
> The tag is still pointing to the wrong commit, somehow updating it
> didn't work.
>

Meybe the best solution is to create a b2 . It is not like creating a new name is costly :D

Am Mon, 11 Feb 2013 10:14:47 +0100
schrieb "deadalnix" <deadalnix@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.

On Monday, 11 February 2013 at 09:19:09 UTC, deadalnix wrote:
> On Monday, 11 February 2013 at 08:59:12 UTC, Johannes Pfau wrote:
>> Am Mon, 11 Feb 2013 07:03:07 +0100
>> schrieb "deadalnix" <deadalnix@gmail.com>:
>>
>>> It seemed fixed in previous state of master, so either the tag is wrong or we have a regression. What is the state of 2.062-b1 ?
>>
>> The tag is still pointing to the wrong commit, somehow updating it
>> didn't work.
>>
>
> Meybe the best solution is to create a b2 . It is not like creating a new name is costly :D

So I did some testing.

Master do work fine for me. Staging doesn't compile. The tag is outdated.