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

1100110 0b1100110 at gmail.com
Wed Nov 28 11:02:18 PST 2012


On 11/28/2012 12:05 PM, Joseph Rushton Wakeling wrote:
> 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!

A new module in Phobos is highly unlikely to break anything, So I would 
assume that this would count as a simple bug fix and be merged.


More information about the Digitalmars-d mailing list