[Dlang-internal] dmd semver experiment

[Martin Nowak]

On Sunday, 13 May 2018 at 19:27:50 UTC, Johan Engelen wrote:
> To illustrate the problem, I can share the experience of 
> upgrading to newer compilers at Weka.
> I have yet to experience a compiler upgrade without compilation 
> breakage and without linking breakage, and there have been very 
> serious execution breakage issues too [2]. Fixing the code 
> (e.g. accepts-invalid bugs, deprecations), adding workarounds 
> (regressions, language changes), tracking down compiler or 
> Phobos or code bugs, etc., all take quite some time meaning 
> that actually _testing_ the new compiler only starts after 
> several weeks. This is an optimistic estimate; currently Weka 
> is at dlang 2.076 (LDC 1.6.0) and we now start real testing of 
> dlang 2.078 (LDC 1.8.0, released over 2 months ago). As you can 
> see, Weka is skipping versions, mainly because of the time it 
> takes to upgrade the compiler is longer than the period between 
> compiler releases.
> Recent events [2] made people at Weka and me much more wary of 
> compiler updates, and perhaps the testing phase will also take 
> longer than before.
>
>
> I feel currently the project is racing at too high speed 
> pumping out releases, at the cost of quality and carefulness 
> that I feel is appropriate for compiler/language development 
> (adding to existing quality-of-implementation problems).
> Thus I am very much in favor of major releases every half year 
> (or longer), with only minor releases in-between that do not 
> add new features or language changes.

Just saw this discussion today, glad to finally get some feedback 
on this.

You should also consider that a slower release cycle means bigger 
releases with more issues and regresssions. We've done that in 
the past and from my point upgrading releases was a lot worse 
back then, having to deal with 10 issues instead of 1 or 2.

Still I agree with you that 6 breaking releases per year is too 
much.
The proposed half-yearly major releases with bi-monthly minor 
releases scheme should make releases more predictable, without 
changing the current release scheme too much.

For this to work well, we should prolly open up stable for small, 
strictly backwards compatible additions like new C bindings in 
druntime, enum additions, maybe even tiny new phobos functions.
What's important is API/ABI-compatibility and to not break code 
in minor releases.

-Martin