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