On Tuesday, July 31, 2012 01:10:35 Walter Bright wrote: > On 7/30/2012 11:24 PM, Russel Winder wrote: > > On Mon, 2012-07-30 at 23:40 -0400, Andrei Alexandrescu wrote: > > […] > > > >> Walter and I will dedicate time after 2.060 to improving the process. > > > > "Improve" implies tinkering at the edges. This situation requires a > > "change" or perhaps "revolution". I suggest just switching to a > > ready-made DVCS / Git process that is known to work, and is well > > documented, rather than trying to craft a new one based on CVCS / > > Subversion / CVS history. > > We're already using Git.
The complaint is that we're using git as if it were subversion. We never branch, whereas you usually branch quite heavily when using git. If we were using git like it's normally used, we'd be branching for betas (as well as splitting the new feature development branch from the bugfix branch). Instead, we have a single branch that we do everything on, forcing us to stop merging any pull requests when we do a beta. The typical way to do this with git involves using multiple branches, not doing everything on trunk/master. The simplest way to do this would probably be to branch for a release whenever we do a beta. We then continue to merge stuff into master as normal. But when there's a fix that we need for the beta, we cherry pick it from master and put it in the release branch. And when the release is finally ready to go, we tag the appropriate commit on the release branch, and that's the release. That way, doing a beta does not halt normal development at all. Rather, it's done in parallel. If we take this further as most large open source projects do and had a 2.x.y versioning model, then the work for x would be on master, and we'd cherry pick bug fixes to the y branch as we went along. Then at intervals, we'd branch y to create a release branch and do the beta and subsequent release from that. So, we'd be doing bug fix releases based on the y branch at regular intervals (probably monthly) which didn't include any new features at all. In theory, this promotes greater stability. So, we'd get 2.60.0, 2.60.1, 2.60.2, etc. Then at some larger interval (generally 6 - 12 months, depending on the project; we'd probably want to do 6 months at this point), we'd branch x to create a new y branch and start using that as the bugfix branch. So, the first release from that would include all of the new features that had been being worked on over the previous 6 months. So, if we'd been releasing 2.60.y we'd get a 2.61.0 release at that point, and the subsequent releases would be 2.61.1, 2.61.2, etc. That model is essentially what was being argued for in the newsgroup recently which ended up with dlang-stable being created. There are a variety of articles online describing branching/release models along those lines, but that's typically what happens with git on the most basic level. You branch heavily (and actually, as described here, the number of branches is quite light for git). A more complicated scheme which was recently brought up in the newsgroup is described here: http://nvie.com/posts/a-successful-git-branching-model/ But I very much doubt that we want to do anything quite that complicated. Regardless, the fact that we don't even branch for a beta is a definite indicator that we're using git as if it were subversion. If we were _really_ using git as intended, then not only would we be branching for betas and for the releases, but we'd be creating temporary branches for new features as they're ironed out (merging them into master only when they're completed). - Jonathan M Davis
