Is it time for D 3.0?

[Joseph Rushton Wakeling]

On Wednesday, 1 April 2020 at 05:30:41 UTC, Mathias LANG wrote:
> On Tuesday, 31 March 2020 at 23:25:31 UTC, Joseph Rushton 
> Wakeling wrote:
>> Yup, assuming the current 3-month release cadence continues it 
>> would make sense to make all breaking changes in only one of 
>> those 4 quarterly releases.  A Christmas present to the 
>> community? O:-)
>
> That would be a step... Sideways ?
>
> Currently we follow this: 
> https://github.com/dlang/DIPs/blob/5afe088809bed47e45e14c9a90d7e78910ac4054/DIPs/accepted/DIP1013.md

Yup, right.  So however many releases there are in a year (4 
quarterly, or 6 bimonthly), the removal schedule is based on the 
number of releases since something got deprecated.

Now suppose that in 6 different successive releases you deprecate 
one thing each.  If you follow the 10-releases-later rule then, 
10 releases down the line, you wind up with 6 successive releases 
all making breaking changes.

What I'm suggesting is that instead we could have a once-a-year 
breaking-change release.  So, if a feature is deprecated, then it 
gets removed 10 releases later or at the next annual 
breaking-change point, _whichever is later_.

So, it's a little bit sideways, but it's a lot more predictable 
and allows dev teams to plan around it much more robustly.  And 
note that this doesn't shorten deprecation periods -- on average, 
it will slightly increase them.

Of course, I imagine that in practice where there are multiple 
breaking changes to make they _do_ get bundled together rather 
than strictly sticking to a 10-releases-later rule.  But if 
that's at the discretion of maintainers rather than an official 
policy, it's a lot less easy to plan around it.

> Personally, the main disruption I had over the last 2 years was 
> the concurrent GC (a new feature) being enabled by default. 
> There was hardly any breaking change.

Sure.  That's why I asked earlier where the breaking changes are 
coming from.  We can control for when we schedule planned 
breaking change (and here SemVer is useful).  But if most of the 
breaking changes are unplanned regressions, we have a different 
problem.

> With the current 10-release deprecation period and 3-months 
> between release, this means a deprecation is up for 30 months, 
> or 2 1/2 years before being removed. I don't think we should 
> shorten it any further, it already proved problematic on some 
> occasions (e.g. body => do).

Yea, this was inadequate communication on my part.  As explained 
above, I wasn't suggesting shortening the deprecation period.