Next focus: PROCESS

[Joseph Rushton Wakeling]

On 12/11/2012 12:41 AM, Andrei Alexandrescu wrote:
> In turn, I'll be collecting thoughts and opinions in this thread, distilled from
> previous discussions. We should develop a few simple git scripts (such as
> git-start-new-feature or git-start-bugfix etc) supported by an equally simple
> piece of documentation describing how to start a new release, fix a bug,
> experiment with a new feature, and such.
>
> (One piece that has been brought forward is
> http://nvie.com/posts/a-successful-git-branching-model/ - something to keep in
> mind.)
>
> Please chime in with ideas and thoughts.

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.

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?

    * STABLE/Long-term support releases would be guaranteed to receive bugfixes
      and have no breaking changes for 3 years.

    * A new LTS release would be made every 2 years, so that there would be a
      1-year overlap between the current LTS release and the previous one.

    * Optionally, non-breaking new features could be included in LTS release
      updates during this timeframe, subject to strict testing.  Such new
      feature updates should only go to the latest LTS release (so, during the
      1-year overlap period, the older LTS would continue to receive bugfixes
      but not have new features added).  The process for including new features
      should probably be more liberal for Phobos than for other parts of the D
      toolchain.

    * In between LTS releases, there should be regular (3- or 6-monthly?)
      interim releases that have gone through testing and are considered
      'stable' in a working sense.  These releases _can_ make breaking changes,
      subject to strict conditions, and should be more liberal about new feature
      inclusion in general.  The idea should be that the interim releases
      converge towards the next LTS release, so the conditions for make breaking
      changes and the testing of new features both become more and more
      stringent the closer to the next LTS release you are.

    * For preference, deprecated features to be 'removed' by simply removing
      documentation and support for a feature rather than removing the feature
      itself (thinking here particularly of Phobos and Walter's observations).

The time periods involved could of course be tweaked, e.g. an LTS release might 
be supported for 5 years and be released every 3 or 4.  There could also be an 
even larger-scale cadence (10 years?) for really major redesigns.

The above reflects my personal preference that I'd rather have a language which 
is willing to continue to iron out annoying idiosyncrasies or bad design 
decisions -- but which can still provide a good stable base for development, 
making sure that there is a good overlap period between LTS releases so that 
developers have a substantial amount of time to update their codebases.