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
