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
