Breaking D2 language/spec changes with D1 being discontinued in a month

[Joseph Rushton Wakeling]

On 11/28/2012 12:48 PM, Manu wrote:
> If D stabilised on exactly the feature set it offers right now (or even 3 months
> ago), I wouldn't be interested. The lowest level is brittle, and the high level
> is still missing a couple of little details (rvalues -> ref is the key one for me).
> D's fluidity is actually one of it's biggest selling points as far as I'm
> concerned. D seems to accept that mistakes can be fixed and improvements can be
> made, and it should embrace that to an extent, or you end up with C++ long term.
>
> I think the best approach is one that others have suggested, 2 branches,
> 'stable' which is maintained for 6-12 months, and only receives non-breaking
> fixes after they've been tested for a while, and 'dev', which users accept may
> receive breaking changes at any time. Those users will be happy to adapt their
> code as the language moves forward, as I am.

I'd agree but with one caveat -- how do you handle the case of the standard 
library, or indeed any other library?

Obviously, every library developer can choose between maintaining a version that 
works with stable only; maintaining a stable and 'bleeding-edge' version; or 
just bleeding edge.  Presumably for Phobos you'd choose the second of these. 
But then, how do you handle _new_ functionality that may or may not depend on 
breaking changes to the language?

Given that Phobos is still a moving target with new functionality being added on 
a regular basis, it could be a bit of a disappointment to have to wait as long 
as 6 months to see the latest new features.

The same also applies to the downstream compilers like GDC and LDC -- it would 
be frustrating to have to wait so long to see new functionality available here. 
  One way to handle that might be to first do the work to properly separate out 
the frontend, so that updates can be merged immediately into GDC/LDC's dev 
versions rather than having to wait for each release.

Finally, even in dev I think it would be useful to still have some formal notice 
of deprecation, so that there's time to anticipate changes.  I'd rather not just 
wake up one morning and find that my code no longer compiles!