Next focus: PROCESS

[Jonathan M Davis]

On Wednesday, December 12, 2012 19:04:17 Joseph Rushton Wakeling wrote:
> It seems to me that while process is clearly very important, what's maybe
> necessary first is to identify what the actual results of the process are
> intended to be.  What should a 'stable version' of D actually mean, in
> practice? What should its lifetime be?  Should there be interim releases
> in-between stable versions which can introduce e.g. breaking features, and
> should those be treated only as beta versions or as releases in their own
> right?  How is that coupled (or decoupled) from releases of the library?
> etc.
> 
> I'd personally rather get those issues addressed out before talking about
> git methods, which to be honest I suspect will be similar no matter what
> the release model.

Agreed.

> So, with that in mind, here are some thoughts/suggestions.
> 
> People have talked about Debian's unstable => testing => stable model, but
> instead, why not consider something more akin to Ubuntu's LTS and interim
> releases?

That makes a _lot_ more sense than the unstable => testing => stable model.

I like the idea of having an LTS release at some interval (probably 1 year) 
where that branch has bug fix releases more or less monthly. We then have a dev 
release cycle where we put out a version of the master branch every 2 or 3 
months or so, where it includes whatever new features we want to include but 
haven't been merged into the LTS branch yet. Then with the next major LTS 
release, we merge in all of the new stuff from the master branch so that it's 
essentially up to date with master (possibly modulo some newer features or 
other major changes if they weren't deemed ready yet). So, we then end up with 
the LTS/stable branch having a versioning scheme something like

2.061.1, 2.061.2, 2.061.3, 2.061.4 ... 2.062.1, 2.062.2, ...

and the master/dev branch has a versioning scheme like

2.062.dev1, 2.062.dev2, 2.062.dev3, 2.062, 2.063.dev1, ...

The releases on the master/dev branch which aren't marked with dev are then 
the new major LTS release, which the LTS/stable branch bases its next years 
worth of minor releases off of.

The exact way to name the versions probably needs some work, but the basic 
model sounds fairly straightforward and clean to me. We then have longer term 
releases for those who want stability where they still get bug fixes fairly 
frequently (possibly more frequently than now, since there won't be new 
features being added, causing more risk for releasing), and we continue to 
have dev releases more or less as we have been for those that want new 
features faster.

As for what that means for github and branching, I'd expect us to continue 
more or less as we have been for master except that newer features and other 
major changes would start out on feature branches so that they can be properly 
sorted out before being merged into master, and we'd actually branch when 
doing betas for releases and do the releases from those branches rather than 
master. Then the folks mananging the stable branch would merge in bug fixes as 
we go along, doing their minor releases whenever they feel it's appropriate.

As for the standard library and its releases, I wouldn't really expect them to 
be decoupled from the compiler's releases but rather that they would continue 
more or less as they have been. I think that it's too often the case that 
changes in them need to be made at the same time for it to really work to 
decouple them at this point.

- Jonathan M Davis