Breaking D2 language/spec changes with D1 being discontinued in a month
Maxim Fomin
maxim at maxim-fomin.ru
Wed Nov 28 05:56:51 PST 2012
On Wednesday, 28 November 2012 at 13:36:01 UTC, Walter Bright
wrote:
> On 11/29/2012 12:15 AM, Jacob Carlborg wrote:
>> Many people has also talked about something in between D1 and
>> D2, D1.5
>> or similar. Which would contain bug fixes and new backwards
>> compilable
>> changes.
>
>
> The trouble with that is now I'd be maintaining 3 versions of
> the compiler rather than two.
>
> Here's what happens nearly all the time. People create a pull
> request for a fix to D2. I don't just pull it, I review it and
> see if it is a fix that should be propagated to D1. If it is, I
> have to manually merge it into D1 (as the sources have
> substantially diverged by now). This gets fairly time
> consuming. Check the D1 commits labeled along the lines of
> "merge D2 pull #nnnn".
>
> Only a relatively small handful of times has anyone submitted a
> corresponding pull request for D1.
>
> Adding a 3rd compiler to do this to is a large time sink.
>
> I can see creating a stable D2 and a forward D2 for 6 months at
> a time or so, as has been proposed here. I think that's a good
> idea. But only after D1 is no longer supported.
Thanks for writing this: it explains something regarding slowness
of pull merging.
Have you thought about adjusting D development model to D growth?
Perhaps allowing permissive test branch or delegating parts of
project to maintainers (like with linux)?
Regarding breaking changes vs. keeping cripple features - it is a
trade-off and certainly somebody will be in a loss position.
Probably there is need to set up a clear policy - currently there
are only talks and guesses about each problematic feature.
More information about the Digitalmars-d
mailing list