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

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

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.

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.

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.

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.

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.

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 ?

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.

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.