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.
