Next focus: PROCESS

[foobar]

On Tuesday, 11 December 2012 at 02:02:54 UTC, Andrei Alexandrescu
wrote:
> On 12/10/12 7:19 PM, H. S. Teoh wrote:
>> Sounds OK to me, though it seems unnecessarily complicated.
>
> FWIW there's also this:
>
> http://drewfradette.ca/a-simpler-successful-git-branching-model/
>
>
> Andrei

First of all - Yay!

There are still a few open questions that need to be decided
before a suitable process can be defined.

a. Should we have more than one stable release and provide
support branches?
That means we have version X which is latest stable with all the
latest (stable) features included and we have an older Y version
that only receives bug-fixes and is intended for support (think
of Ubuntu's LTE versions). If we have such additional versions,
how many do we have, for how long?
My opinion - (based on Walter's) you can always download a
previous version of the compiler. I'd say we should _at most_
support _one_ previous stable version with critical bug fixes
only. we could always decide to support ad-hoc additional
specific versions, for example before we introduce major paradigm
shifting changes and this also depends on available manpower.

B. should we have public pre-release versions?
I think we should release additional "releases" - call them beta,
pre-release, release candidates, whatever. These are for staging
changes, allowing to field test new features and language changes
before they are made final. Also allowing users to adjust their
code-bases.

Given the above, I think the "simpler flow" model above looks
very promising and we should adopt it with minor changes:
1. Both "staging" and "release" should be "public" - the website
lists both the stable versions and the staging versions.
2. the development branch should be the master branch for easier
integration with pull requests.

The staging releases (let's call them beta) will provide previews
of upcoming and experimental features to try out without the
promise of a stable API and would be released _monthly_.

The stable releases will be every 3-4 months and will guaranty a
stable API. A user could download DMD-201212 (i.e. this month)
and play around with UDA and of course report bugs, but knowing
that this feature could change syntax or even be completely
removed thus allowing the developers to test stuff out in the
open without committing to anything.