Next focus: PROCESS

[H. S. Teoh]

On Wed, Dec 12, 2012 at 07:04:17PM +0100, 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.

+1. Thanks for the reminder to not lose sight of the forest for the
trees.


> 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.
[...]
> 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.

I like this idea!!

I think this is much better than the current choice of either breaking
existing code and annoying existing users or living with bad design
decisions forever. One year is a good amount of time to upgrade people's
codebases, so we won't be hampered by bad design decisions in the past,
but can move forward with breaking changes. Freezing the language along
with bad design decisions is what made C++ the monster that it is today.

(Of course, the actual overlap times can be tweaked, but I definitely
support the idea of being able to introduce breaking changes *and* not
immediately alienate a good proportion of the userbase.)


T

-- 
The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator.