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