Next focus: PROCESS
Jesse Phillips
Jessekphillips+D at gmail.com
Sat Dec 15 12:32:40 PST 2012
On Saturday, 15 December 2012 at 10:29:55 UTC, Dmitry Olshansky
wrote:
> 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.
Why you don't rewrite is because it is a public branch. Unlike
feature branches which will basically be thrown out everyone on
the development team will need to have staging updated. If we
rewrite history then instead of
$ git pull staging
At random times it will be (I don't know the commands and won't
even look it up)
It just won't be pretty.
I've made modifications to the graphic hoping to illustrate some
thoughts.
http://i.imgur.com/rJVSg.png
This does not depict what is currently described (in terms of
branching). But is what I've written under
http://wiki.dlang.org/Release_Process#Release_Schedule
I see patches going into the LTS-1 (if applicable), the LTS-1 is
then merged into the latest LTS, which is merged into any active
staging, that is then merged into master.
The monthly release don't get bug fixes (just wait for the next
month).
I've removed some version numbering since I don't know if we
should have a distinct numbering for LTS and Monthly. I've
already give some thoughts on this:
http://forum.dlang.org/post/ydmgqmbqngwderfkljde@forum.dlang.org
More information about the Digitalmars-d
mailing list