www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Trying to follow "Preparing a new major release" instructions

reply Walter Bright <newshound2 digitalmars.com> writes:
on http://wiki.dlang.org/Development_and_Release_Process

So, I did the following commands per instructions:

#Make sure you've read "Local repository setup"
git remote update

git checkout staging
git pull upstream staging

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

and they all worked successfully, but the new tag, etc., do not show up here:

https://github.com/D-Programming-Language/dmd/tree/staging
Feb 07 2013
next sibling parent Matt Soucy <msoucy csh.rit.edu> writes:
On 02/08/2013 12:26 AM, Walter Bright wrote:
 on http://wiki.dlang.org/Development_and_Release_Process

 So, I did the following commands per instructions:

 #Make sure you've read "Local repository setup"
 git remote update

 git checkout staging
 git pull upstream staging

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

 and they all worked successfully, but the new tag, etc., do not show up
 here:

 https://github.com/D-Programming-Language/dmd/tree/staging

I'm seeing the tag fine on github. https://github.com/D-Programming-Language/dmd/tree/v2.062-b1
Feb 07 2013
prev sibling next sibling parent reply "Chris Cain" <clcain uncg.edu> writes:
On Friday, 8 February 2013 at 05:26:38 UTC, Walter Bright wrote:
 and they all worked successfully, but the new tag, etc., do not 
 show up here:

 https://github.com/D-Programming-Language/dmd/tree/staging

It appears for me. I click the down-arrow next to "branch: staging" and click on the "tags" tab and "v2.062-b1" appears as expected.
Feb 07 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
On 2/7/2013 9:48 PM, Chris Cain wrote:
 On Friday, 8 February 2013 at 05:26:38 UTC, Walter Bright wrote:
 and they all worked successfully, but the new tag, etc., do not show up here:

 https://github.com/D-Programming-Language/dmd/tree/staging

It appears for me. I click the down-arrow next to "branch: staging" and click on the "tags" tab and "v2.062-b1" appears as expected.

Ah, yes, my mistake.
Feb 07 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 8 February 2013 at 07:17:50 UTC, Walter Bright wrote:
 On 2/7/2013 9:48 PM, Chris Cain wrote:
 On Friday, 8 February 2013 at 05:26:38 UTC, Walter Bright 
 wrote:
 and they all worked successfully, but the new tag, etc., do 
 not show up here:

 https://github.com/D-Programming-Language/dmd/tree/staging

It appears for me. I click the down-arrow next to "branch: staging" and click on the "tags" tab and "v2.062-b1" appears as expected.

Ah, yes, my mistake.

Awesome \o/ I'll test my code against it.
Feb 07 2013
prev sibling next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Thu, 07 Feb 2013 21:26:38 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:

 on http://wiki.dlang.org/Development_and_Release_Process
 
 So, I did the following commands per instructions:
 
 #Make sure you've read "Local repository setup"
 git remote update
 
 git checkout staging
 git pull upstream staging
 
 git tag v2.062-b1 #b1=>first beta
 git push upstream v2.062-b1
 
 and they all worked successfully, but the new tag, etc., do not show
 up here:
 
 https://github.com/D-Programming-Language/dmd/tree/staging

The tag is there but it references the same commit as 2.061. This is because the tag was made on the staging branch, which is correct. But the staging branch hasn't been updated since the last release. (Which is also correct, but we have to do one intermediate release with special transition instructions. Otherwise we have two releases with exactly the same content) To determine what to do now, we have to know when this release is supposed to be shipped. If we can delay it for ~1 Month we can make the transition to the new release process now and the next release will follow the new instructions 100%. If we want to release ASAP the next release will be the intermediate release. BTW: It's very important that the released beta zips are actually based on the created tags! The current release is based on some recent commit, although the tag is set to a commit from a month ago.
Feb 08 2013
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/8/2013 1:15 AM, Johannes Pfau wrote:
 Am Thu, 07 Feb 2013 21:26:38 -0800
 schrieb Walter Bright <newshound2 digitalmars.com>:

 on http://wiki.dlang.org/Development_and_Release_Process

 So, I did the following commands per instructions:

 #Make sure you've read "Local repository setup"
 git remote update

 git checkout staging
 git pull upstream staging

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

 and they all worked successfully, but the new tag, etc., do not show
 up here:

 https://github.com/D-Programming-Language/dmd/tree/staging

The tag is there but it references the same commit as 2.061. This is because the tag was made on the staging branch, which is correct. But the staging branch hasn't been updated since the last release. (Which is also correct, but we have to do one intermediate release with special transition instructions. Otherwise we have two releases with exactly the same content) To determine what to do now, we have to know when this release is supposed to be shipped. If we can delay it for ~1 Month we can make the transition to the new release process now and the next release will follow the new instructions 100%. If we want to release ASAP the next release will be the intermediate release. BTW: It's very important that the released beta zips are actually based on the created tags! The current release is based on some recent commit, although the tag is set to a commit from a month ago.

I followed the instructions in the wiki. If they don't work, they need to be revised.
Feb 08 2013
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Feb 08 2013
parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Feb 08 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 8 February 2013 at 09:16:02 UTC, Johannes Pfau wrote:
 Am Thu, 07 Feb 2013 21:26:38 -0800
 schrieb Walter Bright <newshound2 digitalmars.com>:

 on http://wiki.dlang.org/Development_and_Release_Process
 
 So, I did the following commands per instructions:
 
 #Make sure you've read "Local repository setup"
 git remote update
 
 git checkout staging
 git pull upstream staging
 
 git tag v2.062-b1 #b1=>first beta
 git push upstream v2.062-b1
 
 and they all worked successfully, but the new tag, etc., do 
 not show
 up here:
 
 https://github.com/D-Programming-Language/dmd/tree/staging

The tag is there but it references the same commit as 2.061. This is because the tag was made on the staging branch, which is correct. But the staging branch hasn't been updated since the last release. (Which is also correct, but we have to do one intermediate release with special transition instructions. Otherwise we have two releases with exactly the same content) To determine what to do now, we have to know when this release is supposed to be shipped. If we can delay it for ~1 Month we can make the transition to the new release process now and the next release will follow the new instructions 100%. If we want to release ASAP the next release will be the intermediate release. BTW: It's very important that the released beta zips are actually based on the created tags! The current release is based on some recent commit, although the tag is set to a commit from a month ago.

Well it has been raised that the staging branch is kind of useless. It was useful in early version, but several changes in the process diminished its interest. Should we simply remove it ? Anyway, Walter, you should first update the stagging branch via : #Make sure you've read "Local repository setup" git remote update git checkout master git pull upstream master git checkout staging git pull upstream staging git merge master git push upstream staging I think you forgot that step. On a side note, can we rename regression bug into something else ? The way it is used in the wiki is clearly note what is meant when using the term regression usually. Released bug maybe ? Bug in production ?
Feb 08 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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).
Feb 08 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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 ?
Feb 10 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 10 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 11 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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
Feb 11 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
Feb 11 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 08 Feb 2013 13:09:59 +0100
schrieb "deadalnix" <deadalnix gmail.com>:

 On Friday, 8 February 2013 at 09:16:02 UTC, Johannes Pfau wrote:
 Am Thu, 07 Feb 2013 21:26:38 -0800
 schrieb Walter Bright <newshound2 digitalmars.com>:

 on http://wiki.dlang.org/Development_and_Release_Process
 
 So, I did the following commands per instructions:
 
 #Make sure you've read "Local repository setup"
 git remote update
 
 git checkout staging
 git pull upstream staging
 
 git tag v2.062-b1 #b1=>first beta
 git push upstream v2.062-b1
 
 and they all worked successfully, but the new tag, etc., do 
 not show
 up here:
 
 https://github.com/D-Programming-Language/dmd/tree/staging

The tag is there but it references the same commit as 2.061. This is because the tag was made on the staging branch, which is correct. But the staging branch hasn't been updated since the last release. (Which is also correct, but we have to do one intermediate release with special transition instructions. Otherwise we have two releases with exactly the same content) To determine what to do now, we have to know when this release is supposed to be shipped. If we can delay it for ~1 Month we can make the transition to the new release process now and the next release will follow the new instructions 100%. If we want to release ASAP the next release will be the intermediate release. BTW: It's very important that the released beta zips are actually based on the created tags! The current release is based on some recent commit, although the tag is set to a commit from a month ago.

Well it has been raised that the staging branch is kind of useless. It was useful in early version, but several changes in the process diminished its interest. Should we simply remove it ?

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. I actually like this concept, but you could also prepare releases on the release branch. There are some drawbacks though. (For example a pull request targeting an release branch could be valid before the release, as we still allow all kinds of bug fixes then, but invalid after the release as the criteria for which fixes are allowed changed). The problem here is that the wiki page is missing instructions for the transition from the old process to the new process. 5.3 suggest merging master into staging _after_ an actual release, but this won't work for the transition release as we won't get any new commits into staging (as it happened now). What we really need to do is agree on a release process - starting the transition to the new process only makes sense if all contributors really agree to use the new process. So we need all core developers to issue their concerns, probably adapt the release process and then make plans/instructions for the transition phase. And the _do_ the transition.
Feb 08 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
Am Fri, 08 Feb 2013 02:54:04 -0800
schrieb Walter Bright <newshound2 digitalmars.com>:

 
 I followed the instructions in the wiki. If they don't work, they
 need to be revised.

You followed the instructions but nobody else did. For example bug fixes weren't pushed to staging as described in 5.2.4 and therefore we don't have any bug fix commits in staging now. The instructions on the page can't work correctly if they are only partially followed. 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.
Feb 08 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
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=20 talk and facts several times. =20 Thanks, =20 Andrei

Then I propose this: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For 2.062 release =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * 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=3D>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. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From now on =3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D * 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.) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D For 2.063 release =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 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. =46rom then on we can follow the instructions on the wiki 1:1.
Feb 08 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
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.
Feb 08 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
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.
Feb 11 2013
prev sibling next sibling parent Johannes Pfau <nospam example.com> writes:
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.
Feb 11 2013
prev sibling parent Johannes Pfau <nospam example.com> writes:
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.
Feb 11 2013