github release procedure

Johannes Pfau nospam at example.com
Wed Jan 9 12:40:59 PST 2013


Am Wed, 09 Jan 2013 18:37:15 +0100
schrieb "Jesse Phillips" <Jessekphillips+D at gmail.com>:

> On Thursday, 3 January 2013 at 17:56:05 UTC, Johannes Pfau wrote:
> > 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?
> 
> I strongly disagree here. We want pull requests to be made 
> against the oldest supported/relevant branch. This could be 
> merged to both staging and master (which can simply be done by 
> merging staging into master) there is no need to complicate 
> things with cherry picking.
> 
> As for history, I think that clearly shows what the history is, 
> staging gets fixes and master gets staging that is what we want.

You replied to one of my oldest posts in this discussion ;-)

I didn't understand the staging concept when I wrote that - I think
I've understood most of it now, though. I think the old release process
wiki page wasn't clear enough.

I've updated the http://wiki.dlang.org/Development_and_Release_Process
page last week (I even added a "do not cherry pick from one official
branch into another" rule), so you won't have to convince me ;-)

Do you think the wiki page is good / correct? I've verified that all
git commands work, so if everyone agrees with the workflow (should be
the same as on the old page) we can probably start a new thread and ask
for comments from the core devs.


More information about the Digitalmars-d mailing list