github release procedure

[Johannes Pfau]

Am Wed, 02 Jan 2013 16:58:22 -0800
schrieb Walter Bright <newshound2 at 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 ;-)