On Saturday, 15 December 2012 at 20:32:42 UTC, Jesse Phillips
wrote:
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/ydmgqmbqngwderfkl...@forum.dlang.org
Can we drop the LTS name ? It reminds me of ubuntu, and I clearly
hope that people promoting that idea don't plan to reproduce
ubuntu's scheme :
- it is not suitable for a programming language (as stated 3
time now, so just read before why I won't repeat it).
- ubuntu is notoriously unstable.
