Next focus: PROCESS

[Rob T]

On Wednesday, 12 December 2012 at 18:04:43 UTC, 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 100%. We're going about this completely ass backwards.

Here's my stab at defining the main points to achieve:

1) We want improved stability and predictability with compiler 
releases to prevent a new release from unexpectedly breaking 
existing D code without significant prior warnings and time to 
prepare for it.

2) Stable releases should remain stable while being maintained, 
which means "bug fixes only".

3) We don't want to cast the language in stone, so new features 
must be allowed to be introduced in a more predictable and 
planned way that allows D programmers to confidently use the new 
features in their production code.

4) We want to allow D to continue to be enhanced in a way that 
allows the D compiler developers to do what they do best, while 
not interfering with the growing D user base who wish to rely on 
relative stability and predictability.

Points 3 and 4 may seem the same, but the important difference is 
that there are two types of D users, those who use the language 
and those who develop the language and compiler (a person may do 
both of course), so the goals and requirements for each group of 
user are different and may conflict.

If I write stuff like this in here, it'll just end up 
disappearing into the black hole.

Can we agree to create a wiki page for defining what the main 
goals are, and what we wish to achieve?

Once we have consensus on what is to be achieved, we can define a 
process and test it to see if it will achieve what we want.

This is a much better approach than trying to build a process to 
achieve something that is not yet defined and agreed on.

--rt