Ghosting a language feature

[Mike Parker]

On Monday, 21 September 2020 at 10:39:44 UTC, Walter Bright wrote:

>
> People may not come to D because it has eternal backwards 
> compatibility, but some definitely leave because they got tired 
> of constant breakage.
>
>

Our current release schedule, despite being divided into "major" 
and "patch" releases, is just a string of incremental releases 
every two months. There's nothing to differentiate one major 
release from another -- it's all D2 -- and some may feel pressure 
to update to the latest major compiler release as often as 
possible, risking the headaches of breakage, regressions, and 
with the remedy of only one patch release before it's time to do 
it again.

This situation spawns discussions of D3, std.v2, and now this.

Watching what C++, and especially Java, are doing these days, I 
feel like our approach is antiquated. What we need is an obvious 
way to delineate the feature set of any version of both the 
language and the standard library, and create a path that allows 
for a more leisurely, less risky style of updates.

For example:

* A "milestone" release, say every one or two years, that 
eliminates the 2.x versioning in favor of the year -- D21, D23, 
etc.
* Every release between milestones is a patch release (21.1, 21.2)
* New language and library features are allowed only in milestone 
releases
* Each milestone release is supported with patch releases for a 
fixed number of milestone cycles, and bugfixes that can be 
backported are backported to all supported versions.
* Features can only be deprecated in a milestone release, and are 
removed in a specific milestone release down the road (3 cycles 
or whatever).

With a schedule like this, there's no need for a D3, or a std.v2. 
Ghosting doesn't need to be a thing. We can point specifically to 
the distinct feature sets of D21 and D23 and D25, and Phobos 
21/23/25. I can know that if I choose D21 for my project today, I 
can keep using that specific version of the language, with patch 
release support, until D27 (or whatever) is released. I don't 
have to feel pressure to upgrade to D23, and I can wait until any 
regressions it may have introduced are ironed out before I do 
make the move.

It also allows us to start planning features more coherently (DIP 
10xx has been approved and will be implemented for D25) so that 
the feature set of each milestone release can be mapped out and 
published on the site well before it's released.

My 2 cents.