View mode: basic / threaded / horizontal-split · Log in · Help
January 03, 2013
github release procedure
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.
January 03, 2013
Re: github release procedure
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.
January 03, 2013
Re: github release procedure
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
January 03, 2013
Re: github release procedure
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
January 03, 2013
Re: github release procedure
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 ;-)
January 03, 2013
Re: github release procedure
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).
January 03, 2013
Re: github release procedure
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.
January 03, 2013
Re: github release procedure
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 :-)
January 03, 2013
Re: github release procedure
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.
January 03, 2013
Re: github release procedure
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.
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home