On 2/8/13 8:25 AM, Johannes Pfau wrote:
> I have to admit that the wiki page is missing instructions for the
> transition to the new process. But as long as we don't have a clear
> "Yes we want to use that process" statement from the core developers
> there's no use in writing them. Right now it seems you're the only one
> trying to follow that wiki page.

Yes we want to use that process. I thought we made that clear through talk and facts several times.

Thanks,

Andrei

Am Fri, 08 Feb 2013 10:03:01 -0500
schrieb Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>:

> On 2/8/13 8:25 AM, Johannes Pfau wrote:
> > I have to admit that the wiki page is missing instructions for the transition to the new process. But as long as we don't have a clear "Yes we want to use that process" statement from the core developers there's no use in writing them. Right now it seems you're the only one trying to follow that wiki page.
> 
> Yes we want to use that process. I thought we made that clear through talk and facts several times.
> 
> Thanks,
> 
> Andrei

Then I propose this:

============== For 2.062 release ===========================

* For this release, merge master into staging now
  ("5.3 Preparing a new major release", first code block).

* Delete the wrong tag:
git tag -d v2.062-b1
git push upstream :refs/tags/v2.062-b1

* Create the tag with the correct commit:
git checkout staging
git pull upstream staging

git tag v2.062-b1 #b1=>first beta
git push upstream v2.062-b1

(Update the dmd-beta.zip to match the content of the new tag)

* Continue working on the current release on the staging branch, create
  tags/betas and the release as described on the wiki page (5.3 second
  code block, 5.3 third code block).
  * Fixes for the current release should go directly to staging, normal
    development continues on master. Just as described in 5.2.

============== From now on ===========================

* This also means from now on all pull requests should go to the
  correct branches as described in 5.2. Things like the recent JSON
  changes would get a feature branch, bug fixes to staging, smaller
  enhancements to master.
  (Everyone with push access to the official repo can push pull
  requests to the correct branches, even if they target the wrong
  branch on github.)

============== For 2.063 release ===========================

The we'll have to make one small exception for the next release: Let's say we plan to release 2.063 in 8 weeks, 5 April. Then we should merge master into staging in 4 weeks, 8 March.

From then on we can follow the instructions on the wiki 1:1.

On Friday, 8 February 2013 at 13:21:20 UTC, Johannes Pfau wrote:
> It's still useful. It's supposed to be used for stabilization before an
> actual release. The release branch is only used after the first release
> has been made.
>

Yes I understand the benefit (I proposed the stagging branch in the first place and wrote the first version of the process using it).

But many other parts of the process and don't think it is worth the extra work of keeping stagging and master in sync anymore. It is an hard things, and we just failed at it. Granted, you have to expect some error at the beginning. Let's see how it turns.

As of regression bugs ? It is unclear what they are (as by definition, the proposed process make no sense to fix regressions).

Am Fri, 08 Feb 2013 17:05:32 +0100
schrieb "deadalnix" <deadalnix@gmail.com>:


> 
> As of regression bugs ? It is unclear what they are (as by definition, the proposed process make no sense to fix regressions).

Maybe the definition should be made clearer. The main idea is to never introduce new bugs in maintenance releases. In the end the contributor / release manager makes the judgement call.

On 2/8/2013 7:58 AM, Johannes Pfau wrote:
> ============== For 2.062 release ===========================
>
> * For this release, merge master into staging now
>    ("5.3 Preparing a new major release", first code block).
>
> * Delete the wrong tag:
> git tag -d v2.062-b1
> git push upstream :refs/tags/v2.062-b1
>
> * Create the tag with the correct commit:
> git checkout staging
> git pull upstream staging
>
> git tag v2.062-b1 #b1=>first beta
> git push upstream v2.062-b1

Ok, this is done.

On Friday, 8 February 2013 at 18:24:00 UTC, Walter Bright wrote:
> On 2/8/2013 7:58 AM, Johannes Pfau wrote:
>> ============== For 2.062 release ===========================
>>
>> * For this release, merge master into staging now
>>   ("5.3 Preparing a new major release", first code block).
>>
>> * Delete the wrong tag:
>> git tag -d v2.062-b1
>> git push upstream :refs/tags/v2.062-b1
>>
>> * Create the tag with the correct commit:
>> git checkout staging
>> git pull upstream staging
>>
>> git tag v2.062-b1 #b1=>first beta
>> git push upstream v2.062-b1
>
> Ok, this is done.

I don't know what is the state of -b1 now, but it doesn't compile my code.

dmd: func.c:1206: virtual void FuncDeclaration::semantic3(Scope*): Assertion `type == f' failed.

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 ?

On Friday, 8 February 2013 at 16:20:14 UTC, Johannes Pfau wrote:
> Am Fri, 08 Feb 2013 17:05:32 +0100
> schrieb "deadalnix" <deadalnix@gmail.com>:
>
>
>> 
>> As of regression bugs ? It is unclear what they are (as by definition, the proposed process make no sense to fix regressions).
>
> Maybe the definition should be made clearer. The main idea is to never
> introduce new bugs in maintenance releases. In the end the
> contributor / release manager makes the judgement call.

We are far away from having a release manager. And it doesn't make things clearer on subject. You basically avoided giving any answer to that question by saying someone else should decide.

To me a regression is a bug that exist in version N+1 but doesn't in version N. I though this definition was widespread, but apparently it isn't as the described process make no sense in case of regression.

Am Mon, 11 Feb 2013 07:08:42 +0100
schrieb "deadalnix" <deadalnix@gmail.com>:

> 
> We are far away from having a release manager. And it doesn't make things clearer on subject. You basically avoided giving any answer to that question by saying someone else should decide.

It's difficult to find a clear definition for what bugs should be fixed in minor releases.

> 
> 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 though this definition was widespread, but apparently it isn't as the described process make no sense in case of regression.

Why doesn't it make sense? In other projects minor releases are usually bug fix releases so they don't introduce new functionality. If you take dmd a _huge_ part of development is bug fixes and with that many fixes it's likely that some introduce new bugs. But that's exactly what you want to avoid when releasing a minor release. You want a release with some bugs fixed and no new bugs introduced.

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.

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.

Maybe we should just do this release as usual. After this release has been made we could discuss a release schedule first so that we now when 2.063 will be released. And then we can make a clear plan on how to switch to the new process.

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.

> 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.