digitalmars.D - Trying to follow "Preparing a new major release" instructions
- Walter Bright (10/10) Feb 07 2013 on http://wiki.dlang.org/Development_and_Release_Process
- Matt Soucy (3/14) Feb 07 2013 I'm seeing the tag fine on github.
- Chris Cain (4/7) Feb 07 2013 It appears for me. I click the down-arrow next to "branch:
- Walter Bright (2/8) Feb 07 2013 Ah, yes, my mistake.
- deadalnix (3/15) Feb 07 2013 Awesome \o/
- Johannes Pfau (16/33) Feb 08 2013 The tag is there but it references the same commit as 2.061. This is
- Walter Bright (3/36) Feb 08 2013 I followed the instructions in the wiki. If they don't work, they need t...
- Johannes Pfau (11/14) Feb 08 2013 You followed the instructions but nobody else did. For example bug
- Andrei Alexandrescu (5/10) Feb 08 2013 Yes we want to use that process. I thought we made that clear through
- Johannes Pfau (36/49) Feb 08 2013 Then I propose this:
- Walter Bright (2/13) Feb 08 2013 Ok, this is done.
- deadalnix (7/24) Feb 10 2013 I don't know what is the state of -b1 now, but it doesn't compile
- Johannes Pfau (8/10) Feb 11 2013 The tag is still pointing to the wrong commit, somehow updating it
- deadalnix (18/61) Feb 08 2013 Well it has been raised that the staging branch is kind of
- Johannes Pfau (21/75) Feb 08 2013 It's still useful. It's supposed to be used for stabilization before an
- deadalnix (11/16) Feb 08 2013 Yes I understand the benefit (I proposed the stagging branch in
- Johannes Pfau (5/9) Feb 08 2013 Maybe the definition should be made clearer. The main idea is to never
- deadalnix (8/18) Feb 10 2013 We are far away from having a release manager. And it doesn't
- Johannes Pfau (21/31) Feb 11 2013 It's difficult to find a clear definition for what bugs should be fixed
- deadalnix (7/25) Feb 11 2013 I try to understand the whole thing. If a bug exists in N+1, but
- Johannes Pfau (21/53) Feb 11 2013 Where did you get that impression? We should really fix that part of
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
Matt Soucy <msoucy csh.rit.edu> 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/stagingI'm seeing the tag fine on github. https://github.com/D-Programming-Language/dmd/tree/v2.062-b1
Feb 07 2013
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/stagingIt 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
On 2/7/2013 9:48 PM, Chris Cain wrote:On Friday, 8 February 2013 at 05:26:38 UTC, Walter Bright wrote:Ah, yes, my mistake.and they all worked successfully, but the new tag, etc., do not show up here: https://github.com/D-Programming-Language/dmd/tree/stagingIt 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
On Friday, 8 February 2013 at 07:17:50 UTC, Walter Bright wrote:On 2/7/2013 9:48 PM, Chris Cain wrote:Awesome \o/ I'll test my code against it.On Friday, 8 February 2013 at 05:26:38 UTC, Walter Bright wrote:Ah, yes, my mistake.and they all worked successfully, but the new tag, etc., do not show up here: https://github.com/D-Programming-Language/dmd/tree/stagingIt 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
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/stagingThe 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
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>:I followed the instructions in the wiki. If they don't work, they need to be revised.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/stagingThe 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
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
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
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: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.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.=20 Yes we want to use that process. I thought we made that clear through=20 talk and facts several times. =20 Thanks, =20 Andrei
Feb 08 2013
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
On Friday, 8 February 2013 at 18:24:00 UTC, Walter Bright wrote:On 2/8/2013 7:58 AM, Johannes Pfau wrote: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 ?============== 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-b1Ok, this is done.
Feb 10 2013
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
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>:Meybe the best solution is to create a b2 . It is not like creating a new name is costly :DIt 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.
Feb 11 2013
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:So I did some testing. Master do work fine for me. Staging doesn't compile. The tag is outdated.Am Mon, 11 Feb 2013 07:03:07 +0100 schrieb "deadalnix" <deadalnix gmail.com>:Meybe the best solution is to create a b2 . It is not like creating a new name is costly :DIt 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.
Feb 11 2013
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>: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 ?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/stagingThe 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
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: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.Am Thu, 07 Feb 2013 21:26:38 -0800 schrieb Walter Bright <newshound2 digitalmars.com>: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 ?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/stagingThe 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
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
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
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>: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.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 10 2013
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 release. I don't know why this wouldn't make sense.
Feb 11 2013
On Monday, 11 February 2013 at 08:54:53 UTC, Johannes Pfau wrote: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.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.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 your 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
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: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.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.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.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.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 your 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