12/14/2012 3:34 AM, deadalnix пишет:
On Thursday, 13 December 2012 at 20:48:30 UTC, deadalnix wrote:
On Thursday, 13 December 2012 at 20:04:50 UTC, Dmitry Olshansky wrote:
I think it's good.
But personally I'd expect:
* master to be what you define as dev, because e.g. GitHub puts
master as default target branch when making pull requests. Yeah, I
know it's their quirk that it's easy to miss. Still leaving less
burden to check the branch label for both reviewers and pull authors
is a net gain.
* And what you describe as master (it's a snapshot or a pre-release
to me) to be named e.g. staging.
And we can as well drop the dead branch 'dev' then.
That sound also like a good plan to me.
Updated to follow the idea, plus added bunch of process description.
Feel free to comment in order to refine this.
http://wiki.dlang.org/Release_Process
I wasn't comfortable doing speculative edits to the wiki directly so
here a few more comments:
I think one of major goals is to be able to continue ongoing development
while at the _same time_ preparing a release. To me number one problem
is condensed in the statement "we are going to release do not merge
anything but regressions" the process should sidestep this "lock-based"
work-flow. Could be useful to add something along these line to goals
section. (i.e. the speed and smoothness is a goal)
Second point is about merging master into staging - why not just rewrite
it with master branch altogether after each release?
master is the branch with correct history (all new stuff is rebased on
it) thus new staging will have that too.
--
Dmitry Olshansky
