Am Fri, 4 Jan 2013 07:46:55 -0800 schrieb "H. S. Teoh" <hst...@quickfur.ath.cx>:
> > I like what you did with the page. I think it makes it a lot clearer. > I read through "Release Schedule" and "Branching model", and I think > it pretty much captures what I described as approach (2). > Yes. The original workflow described in the wiki should be very similar, except that I removed staging. > If this approach is more suitable for the core devs, then I think we > should go with it. I also created a version with staging: http://wiki.dlang.org/User:Jpf/Release_Process_Staging It occurred to me that there is one detil where staging is really useful: If we have bugfix pull requests which target a version branch which is stabilizing (e.g 2.062) that's fine. But if those aren't merged when 2.062 is released, all open pull requests will still target 2.062 but they should target 2.063 instead. So we have to cycle through all pull requests and ask the contributors to retarget 2.063. With staging bug fixes can just always target staging and this is not an issue. I think in the end the core devs should choose. But it seems like an extra staging is more difficult to understand but can avoid some additional work in long term. > Whether or not one is a git expert ought not matter, if we define the > process sufficiently clearly that one can simply look up the wiki page > and type in the commands as-is, like a script, as Walter puts it. The > important point is to agree on a single implementation of the process, > and supply complete and unambiguous series of git commands to carry > out the process. I agree. I try to do that on the wiki page, but I can't guarantee that it's complete.
