github release procedure

[Jacob Carlborg]

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