github release procedure

[Johannes Pfau]

Am Thu, 03 Jan 2013 03:51:48 +0100
schrieb "Jason House" <jason.james.house at 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).