Pull freeze

[Jonathan M Davis]

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