As always, when I try to do a release, problems crop up. For example,
the github procedure agreed upon and outlined here:

http://wiki.dlang.org/Proposed_new_D_development_process#Release_a_new_version_of_D

Issues:

1. you cannot have a tag and a branch with the same name. At least, you cannot push them with:

    git push origin 2.N+1

because it's ambiguous. So I prepended a v to the tag name.

2. The:

   git checkout staging
   git merge master

It merges master into staging, wiping out my changes in staging, and does not delete staging. Now that the release is done, we're done with staging. What is needed is the ability to merge from staging to master all commits in staging that occurred after it branched off from master.

I did this by going through the git commit history and cherry-picking one by one. There's got to be better way.

3. There is no mention of where and when the:

   git push

and:

   git pull

get done. I also had to add staging to .git/config, can that be done from the push & pull command?

4. I think that staging should be deleted after the branch is done?

5. Since essentially the staging branch gets replaced by the 2.061 branch, why have a staging branch at all? Just make a 2.061 branch, then tag it when the release happens.

On Thursday, 3 January 2013 at 00:59:04 UTC, Walter Bright wrote:
> As always, when I try to do a release, problems crop up. For example,
> the github procedure agreed upon and outlined here:
>
> http://wiki.dlang.org/Proposed_new_D_development_process#Release_a_new_version_of_D
>
> Issues:
>
> 1. you cannot have a tag and a branch with the same name. At least, you cannot push them with:
>
>     git push origin 2.N+1
>
> because it's ambiguous. So I prepended a v to the tag name.

It looks like branch should be 2.N while tags are 2.N.M. It looks like the base of branch 2.N will be tagged as 2.N.0. If minor changes are needed, they go into the 2.N branch, and when ready the next tag on that branch will be 2.N.1, then 2.N.2, etc...


> 2. The:
>
>    git checkout staging
>    git merge master
>
> It merges master into staging, wiping out my changes in staging, and does not delete staging. Now that the release is done, we're done with staging. What is needed is the ability to merge from staging to master all commits in staging that occurred after it branched off from master.

I believe the intent of staging is to get stable snapshots of master. At a minimum, I believe you'd merge master into staging when you're ready to do a dmdbeta release. I would recommend merging master into staging more frequently, but definitely not as often as master.

On Thursday, 3 January 2013 at 00:59:04 UTC, Walter Bright wrote:
> 1. you cannot have a tag and a branch with the same name. At least, you cannot push them with:
>
>     git push origin 2.N+1
>
> because it's ambiguous. So I prepended a v to the tag name.

This is okay – the leading 'v' for version tags is common practice with Git, and if the Git workflow described on the wiki is intended to be official, it should be updated to reflect that (in a hurry right now, so I'll pass).

David

On 2013-01-03 01:58, Walter Bright wrote:
> As always, when I try to do a release, problems crop up. For example,
> the github procedure agreed upon and outlined here:
>
> http://wiki.dlang.org/Proposed_new_D_development_process#Release_a_new_version_of_D
>
>
> Issues:
>
> 1. you cannot have a tag and a branch with the same name. At least, you
> cannot push them with:
>
>      git push origin 2.N+1
>
> because it's ambiguous. So I prepended a v to the tag name.

That is the convention used by git.

> 2. The:
>
>     git checkout staging
>     git merge master
>
> It merges master into staging, wiping out my changes in staging, and
> does not delete staging. Now that the release is done, we're done with
> staging. What is needed is the ability to merge from staging to master
> all commits in staging that occurred after it branched off from master.
>
> I did this by going through the git commit history and cherry-picking
> one by one. There's got to be better way.

Can't you just merge staging into master?

> 3. There is no mention of where and when the:
>
>     git push
>
> and:
>
>     git pull

Reading "Release a new version of D", I would say that after you run "git checkout staging" you need to make sure that you're local changes the the upstream changes are in sync. That can mean that you need to both run "git push" and "git pull".

After that the tag needs to be pushed. If you then also merges master into staging that should be pushed as well.

> get done. I also had to add staging to .git/config, can that be done
> from the push & pull command?
>
> 4. I think that staging should be deleted after the branch is done?
>
> 5. Since essentially the staging branch gets replaced by the 2.061
> branch, why have a staging branch at all? Just make a 2.061 branch, then
> tag it when the release happens.


-- 
/Jacob Carlborg

Am Wed, 02 Jan 2013 16:58:22 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> 
> 2. The:
> 
>     git checkout staging
>     git merge master
> 
> It merges master into staging, wiping out my changes in staging

What changes? All changes should be made in master, then applied to staging via cherry picking. So there should never be changes in staging that are not in master so there's nothing that could be overwritten?

>, and does not delete staging. Now that the release is done, we're done
> with staging.

Why would you want to delete staging? This could be done, but I don't see the benefit. Actually staging is quite redundant afaik. Why not just create the release branch directly when we start to prepare a release, then cherry pick from master into that release branch (but never the other way round). Once the release is stable, give it a tag. Then leave the branch alone (or continue the branch by cherry picking further commits for a bugfix 2.061.1 release)

What's the benefit of first cherry-picking into staging and the creating the release branch? If we use release branches directly we can avoid the merge from master to staging after every release as we'll just create a new branch for the new release. (Mixing cherry picking and merging isn't exactly a best practice)

> What is needed is the ability to merge from staging to
> master all commits in staging that occurred after it branched off
> from master.

Wait- The wiki page isn't too clear here ("Development takes place on the master branch"), but as far as I understand all changes should go to master first. Even if those are bugfixes which will be used in staging. The those will be cherry picked into staging if necessary. We should never merge staging into master.

> 
> I did this by going through the git commit history and cherry-picking one by one. There's got to be better way.

We should cherry pick one by one from master into staging. But we should never have to merge anything from staging back into master.

(Technically you can probably pick many commits at once, so it's not
really one by one)
> 
> 3. There is no mention of where and when the:
> 
>     git push
> 
> and:
> 
>     git pull
> 
> get done. I also had to add staging to .git/config, can that be done from the push & pull command?

git fetch origin #update remote branch list
git checkout staging #should automatically track origin/staging

The wiki page could need some enhancements regarding pushing/pulling.

> 
> 4. I think that staging should be deleted after the branch is done?

I don't know why staging was proposed. As described above I don't know
why it's necessary.

> 5. Since essentially the staging branch gets replaced by the 2.061 branch, why have a staging branch at all? Just make a 2.061 branch, then tag it when the release happens.

Ah right, exactly my question. I should have read the whole message first ;-)

Am Thu, 03 Jan 2013 03:51:48 +0100
schrieb "Jason House" <jason.james.house@gmail.com>:

> On Thursday, 3 January 2013 at 00:59:04 UTC, Walter Bright wrote:
> > As always, when I try to do a release, problems crop up. For
> > example,
> > the github procedure agreed upon and outlined here:
> >
> > http://wiki.dlang.org/Proposed_new_D_development_process#Release_a_new_version_of_D
> >
> > Issues:
> >
> > 1. you cannot have a tag and a branch with the same name. At least, you cannot push them with:
> >
> >     git push origin 2.N+1
> >
> > because it's ambiguous. So I prepended a v to the tag name.
> 
> It looks like branch should be 2.N while tags are 2.N.M. It looks like the base of branch 2.N will be tagged as 2.N.0. If minor changes are needed, they go into the 2.N branch, and when ready the next tag on that branch will be 2.N.1, then 2.N.2, etc...

This would mean changing the dmd versioning. We currently don't increase the second number.

To match our versioning, branch should be 2.0.N and tag should be 2.0.N.M. But I like Walter's proposal more, as 2.0.61 should be the same as 2.0.60.0 anyway so the .0 is redundant.


> I believe the intent of staging is to get stable snapshots of master. At a minimum, I believe you'd merge master into staging when you're ready to do a dmdbeta release. I would recommend merging master into staging more frequently, but definitely not as often as master.

This would be an explanation, but we'd have to define what "stable snapshot" means. If it's just "staging must always compile" that's ok. But everything more advanced will need someone to review every single commit. And when we actually want to prepare a release we need all commits / new features anyway?

Imho staging isn't really necessary. We need a branch for every "big" release, 2.0.60, 2.0.61 and so on. Then we add tags, v2.0.60 v2.0.61 and if we wan't a stable dmd, we use one of the release branches (e.g. 2.0.61) cherry pick bugfixes from master and the add a v2.0.61.1 tag and release that.


What I think is weird in the current workflow is that we branch the release branch if we actually ship the release (after beta testing, etc). Why not just start the release branch if we start to prepare the release (before beta testing).

On 1/3/2013 10:11 AM, Johannes Pfau wrote:
> What I think is weird in the current workflow is that we branch the
> release branch if we actually ship the release (after beta testing,
> etc). Why not just start the release branch if we start to prepare the
> release (before beta testing).

Yeah, that's what I was thinking.

On 1/3/2013 3:59 AM, Jacob Carlborg wrote:
> On 2013-01-03 01:58, Walter Bright wrote:
>> 2. The:
>>
>>     git checkout staging
>>     git merge master
>>
>> It merges master into staging, wiping out my changes in staging, and
>> does not delete staging. Now that the release is done, we're done with
>> staging. What is needed is the ability to merge from staging to master
>> all commits in staging that occurred after it branched off from master.
>>
>> I did this by going through the git commit history and cherry-picking
>> one by one. There's got to be better way.
>
> Can't you just merge staging into master?

And won't that remove the commits that are in master but not in staging?


>> 3. There is no mention of where and when the:
>>
>>     git push
>>
>> and:
>>
>>     git pull
>
> Reading "Release a new version of D", I would say that after you run "git
> checkout staging" you need to make sure that you're local changes the the
> upstream changes are in sync. That can mean that you need to both run "git push"
> and "git pull".
>
> After that the tag needs to be pushed. If you then also merges master into
> staging that should be pushed as well.

I know there need to be push's and pull's. The question is the sequence, and the actual commands, like push origin or just push.

The trouble is the wiki lists a sequence of commands, but assumes the user realizes that there are a bunch of other commands that need to be interleaved.

Imagine it's a script. Steps cannot be skipped :-)

On 1/3/2013 9:56 AM, Johannes Pfau wrote:
> Am Wed, 02 Jan 2013 16:58:22 -0800
> schrieb Walter Bright <newshound2@digitalmars.com>:
>
>>
>> 2. The:
>>
>>      git checkout staging
>>      git merge master
>>
>> It merges master into staging, wiping out my changes in staging
>
> What changes? All changes should be made in master, then applied to
> staging via cherry picking.

I think that's a vast assumption that there would never be changes specific to the release.


>> , and does not delete staging. Now that the release is done, we're done
>> with staging.
>
> Why would you want to delete staging? This could be done, but I don't
> see the benefit.

Turn that around - what's the benefit of keeping it? It's just clutter.


> What's the benefit of first cherry-picking into staging and the
> creating the release branch?

Beats me. That's why I asked.

>> 3. There is no mention of where and when the:
>>
>>      git push
>>
>> and:
>>
>>      git pull
>>
>> get done. I also had to add staging to .git/config, can that be done
>> from the push & pull command?
>
> git fetch origin #update remote branch list
> git checkout staging #should automatically track origin/staging
>
> The wiki page could need some enhancements regarding pushing/pulling.

As I suggested to Jacob, if the wiki lists git command sequences, it should be complete (like a script), and not full of assumptions about other commands that need to be inserted.

Am Thu, 03 Jan 2013 10:54:25 -0800
schrieb Walter Bright <newshound2@digitalmars.com>:

> On 1/3/2013 3:59 AM, Jacob Carlborg wrote:
> > On 2013-01-03 01:58, Walter Bright wrote:
> >> 2. The:
> >>
> >>     git checkout staging
> >>     git merge master
> >>
> >> It merges master into staging, wiping out my changes in staging, and does not delete staging. Now that the release is done, we're done with staging. What is needed is the ability to merge from staging to master all commits in staging that occurred after it branched off from master.
> >>
> >> I did this by going through the git commit history and cherry-picking one by one. There's got to be better way.
> >
> > Can't you just merge staging into master?
> 
> And won't that remove the commits that are in master but not in staging?

No, merging will never remove commits. You aren't really supposed to delete commits in git as it can lead to all kinds of trouble and therefore deleting has to be done explicitly.

But I still advise not to merge staging into master. As all commits should go to master first there should be no need to merge back.

If we have commits in staging now which are not in master you can probably merge them into master. It won't look nice in the git history but I shouldn't be a real problem.

> 
> I know there need to be push's and pull's. The question is the sequence, and the actual commands, like push origin or just push.

The 'remote' to which you push the changes actually depends on your setup. 'origin' is called a 'remote' and it's the repository where you've git cloned from. So in a simple setup, it's always push origin.

Git can also 'track' branches. In that case your local branch tracks a 'remote' + branch. In that case you can use git push and it'll push to the tracked remote branch. If you didn't create the staging branch manually but just used git checkout staging it should be tracking origin automatically. Anyway, you can just try git push, as long as you don't have other remotes than origin, nothing can go wrong.

(you can use git remote to show all remotes)

> 
> The trouble is the wiki lists a sequence of commands, but assumes the user realizes that there are a bunch of other commands that need to be interleaved.
> 
> Imagine it's a script. Steps cannot be skipped :-)

I'll update the wiki if nobody outpaces me. But I'd like to have some feedback/conclusion on the staging issue first.