January 08
On Wednesday, 3 January 2018 at 04:50:51 UTC, Martin Nowak wrote:
> We would still keep the bi-monthly releases, but make them point releases.
> So new additions could still be released regularly, but breaking changes and deprecations would have to wait until the next major release.

You probably mean minor releases. Point ones can only contain bug fixes and no features.


January 14
On Monday, 8 January 2018 at 06:21:05 UTC, Dicebot wrote:
> On Wednesday, 3 January 2018 at 04:50:51 UTC, Martin Nowak wrote:
>> We would still keep the bi-monthly releases, but make them point releases.
>> So new additions could still be released regularly, but breaking changes and deprecations would have to wait until the next major release.
>
> You probably mean minor releases. Point ones can only contain bug fixes and no features.

Yes, semver uses the less confusion terms MINOR (bi-monthly) and PATCH (bugfixes).
January 14
On 2018-01-14 20:04, Martin Nowak via Dlang-internal wrote:
> On Monday, 8 January 2018 at 06:21:05 UTC, Dicebot wrote:
>> On Wednesday, 3 January 2018 at 04:50:51 UTC, Martin Nowak wrote:
>>> We would still keep the bi-monthly releases, but make them point releases.
>>> So new additions could still be released regularly, but breaking changes and deprecations would have to wait until the next major release.
>> 
>> You probably mean minor releases. Point ones can only contain bug fixes and no features.
> 
> Yes, semver uses the less confusion terms MINOR (bi-monthly) and PATCH
> (bugfixes).

How would that work in terms of development?
Would we need another branch for deprecations and breaking changes?
January 27
On Sunday, 14 January 2018 at 19:11:33 UTC, Sebastian Wilzbach wrote:
> How would that work in terms of development?
> Would we need another branch for deprecations and breaking changes?

No, master would only get merged into stable every 6 month or so.
It means that more development focus would shift towards stable though.
March 08
On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
> v8.0.0 - Jan 1 2018
> v8.0.x - unscheduled patch releases
> v8.1.0 - Mar 1 2018
> v8.1.x - unscheduled patch releases
> v8.2.0 - May 1 2018
> v8.2.x - unscheduled patch releases
> v9.0.0 - Jul 1 2018
> v9.0.x - unscheduled patch releases
> v9.1.0 - Sep 1 2018
> v9.1.x - unscheduled patch releases
> v9.2.0 - Nov 1 2018
> v9.2.x - unscheduled patch releases
> v10.0.0 - Jan 1 2019
> v10.0.x - unscheduled patch releases

Would make sense to release previews of the upcoming major release, maybe every other month to stick with todays pace.

April 06
On Thursday, 8 March 2018 at 18:25:44 UTC, Martin Nowak wrote:
> On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
>> v8.0.0 - Jan 1 2018
>> v8.0.x - unscheduled patch releases
>> v8.1.0 - Mar 1 2018
>> v8.1.x - unscheduled patch releases
>> v8.2.0 - May 1 2018
>> v8.2.x - unscheduled patch releases
>> v9.0.0 - Jul 1 2018
>> v9.0.x - unscheduled patch releases
>> v9.1.0 - Sep 1 2018
>> v9.1.x - unscheduled patch releases
>> v9.2.0 - Nov 1 2018
>> v9.2.x - unscheduled patch releases
>> v10.0.0 - Jan 1 2019
>> v10.0.x - unscheduled patch releases
>
> Would make sense to release previews of the upcoming major release, maybe every other month to stick with todays pace.

These versions make no sense at all as they have no meaning. Why making the change in the major version after 6 months? The API changes during that time may be minimal...

After seeing this I would propose you start doing similar what Java guys decided to do starting with the Java 18.3 (also called Java 10) - to use <year>.<month>.<release> where release is that month's release that increments from 0 up...
April 06
On 4/6/18 02:49, Dejan Lekic wrote:
> On Thursday, 8 March 2018 at 18:25:44 UTC, Martin Nowak wrote:
>> On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
>>> v8.0.0 - Jan 1 2018
>>> v8.0.x - unscheduled patch releases
>>> v8.1.0 - Mar 1 2018
>>> v8.1.x - unscheduled patch releases
>>> v8.2.0 - May 1 2018
>>> v8.2.x - unscheduled patch releases
>>> v9.0.0 - Jul 1 2018
>>> v9.0.x - unscheduled patch releases
>>> v9.1.0 - Sep 1 2018
>>> v9.1.x - unscheduled patch releases
>>> v9.2.0 - Nov 1 2018
>>> v9.2.x - unscheduled patch releases
>>> v10.0.0 - Jan 1 2019
>>> v10.0.x - unscheduled patch releases
>>
>> Would make sense to release previews of the upcoming major release,
>> maybe every other month to stick with todays pace.
>
> These versions make no sense at all as they have no meaning. Why making
> the change in the major version after 6 months? The API changes during
> that time may be minimal...
>
> After seeing this I would propose you start doing similar what Java guys
> decided to do starting with the Java 18.3 (also called Java 10) - to use
> <year>.<month>.<release> where release is that month's release that
> increments from 0 up...

I completely agree with this. I use some variation of year.month.x(.y) for all my projects. The point in time is non-arbitrary information and encoding it will make identifying builds that are compatible with given modules simpler: 18.x, 18.6, etc.

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;
May 13
On Thursday, 8 March 2018 at 18:25:44 UTC, Martin Nowak wrote:
> On Wednesday, 1 November 2017 at 10:48:15 UTC, Martin Nowak wrote:
>> v8.0.0 - Jan 1 2018
>> v8.0.x - unscheduled patch releases
>> v8.1.0 - Mar 1 2018
>> v8.1.x - unscheduled patch releases
>> v8.2.0 - May 1 2018
>> v8.2.x - unscheduled patch releases
>> v9.0.0 - Jul 1 2018
>> v9.0.x - unscheduled patch releases
>> v9.1.0 - Sep 1 2018
>> v9.1.x - unscheduled patch releases
>> v9.2.0 - Nov 1 2018
>> v9.2.x - unscheduled patch releases
>> v10.0.0 - Jan 1 2019
>> v10.0.x - unscheduled patch releases
>
> Would make sense to release previews of the upcoming major release, maybe every other month to stick with todays pace.

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. Currently, there is no separation of the two. Because DMD's releases are not tested well [1], this results in there not being high quality releases of DMD: each new release is a combination of improved quality (bug fixes) and reduced quality (new features / language changes / regressions). From my personal experience, this leads to there not being a good version to upgrade to. Whichever version is chosen, it always comes with improvements _and_ regressions.

As an unfortunate side-effect of DMD's release pace, LDC has also been releasing at breakneck speed, in order to provide an LDC version for every major dlang version (e.g 2.077, 2.078, ...). Traditionally LDC releases are based on patched DMD releases (e.g. 2.079.1), sometimes including backporting some fixes from more recent frontend versions. The patched DMD releases are more tested (and fixed) and they thus better meet the higher quality standard that is desirable for LDC as an optimizing production compiler. However, with the current pace, there is simply no time for any real testing any more. Nor is there time to incorporate (most) fixes to issues found on released versions in patched versions, because by the time issues are found and fixed there is already a new major version out (backporting does happen, but, understandably, not sufficiently).

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.

Thanks for your consideration.

Kind regards,
  Johan

[1] the CI testsuites are not at all exhaustive (frequently frustrating LDC development), and I am not aware of large industrial projects participating in testing DMD releases.
[2] struct layout differences between LDC 1.2.0 and 1.6.0 were causing very severe issues, and we actually put in effort trying to revert to LDC 1.2.0 again! Luckily, the revert didn't happen and Weka is still on 1.6.0.


May 15
On 5/13/2018 12:27 PM, Johan Engelen wrote:
> 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.

There's always a tension between people needing things now and being conservative. Additionally, a lot of regressions have come from bug fixes.

The best I can do is if you post a list of the bugzilla regressions most irksome to you, we can prioritize them.
May 15
On Tuesday, 15 May 2018 at 15:17:04 UTC, Walter Bright wrote:
> On 5/13/2018 12:27 PM, Johan Engelen wrote:
>> 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.
>
> There's always a tension between people needing things now and being conservative.

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"?
(if "longer than 2 month between major releases" can be called "conservative" for a programming language...)

> The best I can do is if you post a list of the bugzilla regressions most irksome to you, we can prioritize them.

Thanks but my point was: that's no use. All those bugs are discovered after release, and by the time they are fixed there are 2+ new versions out with their own new set of bugs and regressions. Most often workarounds have to be added for the bugs, only in a few cases is it practical/in-time to fix the compiler (feasible because Weka already has its own fork of LDC [1]).

The 'best' that can be done from my perspective is: do a major release every 6 months. What's the rush? What good have the fast cycles brought? Let's provide time for second thought, contemplating, restraint, and other things that surely would help a mature programming language. Please, currently the taste that sticks is that D is just a small group's hobby language...

- Johan

[1] Because a "fix" is needed that introduces a bug elsewhere, so can't upstream yet. The _minimized_ testcase is 100kbyte full of templates. We are still figuring out how to correctly fix things.

1 2 3 4