May 15, 2018
On 2018-05-13 21:27, Johan Engelen wrote:

> Hi Martin and others,
>    I meant to discuss the current release pace at DConf, but unfortunately I didn't, so writing here instead.
> 
> I feel that the current release pace of DMD is (way) too frequent. I am referring to the pace of compiler and language changes, as opposed to releases with only bug fixes. 
What about an LTS approach that was suggested in the general form [1]. Release as often as we do now and, in addition to that, support an LTS release that will only get bug fixes? The LTS can be released once or twice every year. LDC can choose to only track the LTS releases.

[1] https://forum.dlang.org/post/cgqcbhudipokyumimbua@forum.dlang.org

-- 
/Jacob Carlborg
May 15, 2018
On 5/15/2018 11:51 AM, Johan Engelen wrote:
> I think the "need" of people is exaggerated, and I feel is often argued from purely ones own point of view.
> Shouldn't a professional language lean towards "conservative"?

We've worked hard to provide fixes and enhancements to support Weka, Remedy, Sociomantic, and others who tell me they need this stuff right away. I am not in a position to tell them what they need, although I am guilty of that from time to time :-)

We've had slower release cycles in the past, and those were just as strongly condemned for being slow.

Hence the fundamental tension between those positions.

One option is to more actively participate in the Beta release programs, to identify critical regressions before release.

A good thing is that the D test suite gets added to from every regression, so they won't happen again.
May 25, 2018
On Tuesday, 15 May 2018 at 19:41:16 UTC, Walter Bright wrote:
> We've had slower release cycles in the past, and those were just as strongly condemned for being slow.

Maybe it was before nightlies? To keep buzz the frontpage can have nightly update log. I saw that current release cycle is not fast enough for people that want stuff yesterday, so they use nightlies.
August 22, 2018
On Tuesday, 15 May 2018 at 18:58:56 UTC, Jacob Carlborg wrote:
> What about an LTS approach that was suggested in the general form [1]. Release as often as we do now and, in addition to that, support an LTS release that will only get bug fixes? The LTS can be released once or twice every year. LDC can choose to only track the LTS releases.
>
> [1] https://forum.dlang.org/post/cgqcbhudipokyumimbua@forum.dlang.org

LTS means extra work as someone has to backport fixes to the old release.

While moving more changes to minor releases, and keeping major changes for major releases every 6 months would be about the same effort.
August 22, 2018
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
1 2 3 4
Next ›   Last »