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