github release procedure

Johannes Pfau nospam at example.com
Fri Jan 4 07:14:00 PST 2013


Am Fri, 04 Jan 2013 15:55:01 +0100
schrieb "deadalnix" <deadalnix at gmail.com>:

> On Thursday, 3 January 2013 at 18:58:51 UTC, Walter Bright wrote:
> > Turn that around - what's the benefit of keeping it? It's just 
> > clutter.
> >
> 
> It has been discussed here before, and many people agreed that 
> stagging can go away, as changes made in the proposal made it 
> quite redundant. That sounds the reasonable thing to do.

I just thought about something - maybe staging isn't 100% redundant.
I assume my conclusions on
http://wiki.dlang.org/User:Jpf/Release_Process are correct:

If we want release stabilization time == time between 2 releases i.e.
we start a new release/version branch after every major release: 

Let's say 2.062 is in stabilization phase and we use the 2.062 branch.
Then bugfixes are based on / merged into 2.062 branch. So someone opens
a pull request targeting the 2.062 branch with a bugfix. For some
reason (lack of time) this request isn't merged till 2.062 is released.
After the release only regression fixes should go into 2.062.
But we now have a bugfix (not regression) pull request targeting the
2.062 branch!

Staging completely avoids that issue. So is this reason enough to have
staging?


More information about the Digitalmars-d mailing list