On 2012-11-28 13:41, Walter Bright wrote:

> On the other hand, many people were unhappy with my position of "no
> breaking changes at all outside of clear bug fixes" to D1, which also
> implied "no language enhancements". There were many enhancements to the
> code generation, new platforms, etc., and many CTFE improvements (which
> I more or less regarded as bug fixing). There were also no changes
> allowed that affected binary compatibility.

Please, please try and understand. It's not breaking changes in it self that is the problem. It's how they're handled.

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.

-- 
/Jacob Carlborg

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.

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.

On 2012-11-28 14:35, Walter Bright wrote:

> The trouble with that is now I'd be maintaining 3 versions of the
> compiler rather than two.

I don't know if there would be a point of having D1 if something like D1.5 existed. It would still be as backwards compatible as D1 currently is.

> 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 understand that. It's not feasible for one man to maintain three compilers. You need to be able to delegate to other people. That is regardless if there were a third compiler or not. See Maxim's answer to your post.

> 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.

Since D1 will be discontinued at the end of this year, if nothing has changed. It might be a good idea to start to plan for creating a stable D2.

-- 
/Jacob Carlborg

On 11/28/12 8:35 AM, 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.

The problem with the above is the count of "I", which is too large. We need to switch from "I" to "we" so we can scale up.

Andrei

On Wednesday, 28 November 2012 at 13:15:26 UTC, Jacob Carlborg wrote:
> On 2012-11-28 13:41, Walter Bright wrote:
>
>> On the other hand, many people were unhappy with my position of "no
>> breaking changes at all outside of clear bug fixes" to D1, which also
>> implied "no language enhancements". There were many enhancements to the
>> code generation, new platforms, etc., and many CTFE improvements (which
>> I more or less regarded as bug fixing). There were also no changes
>> allowed that affected binary compatibility.
>
> Please, please try and understand. It's not breaking changes in it self that is the problem. It's how they're handled.
>
> 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.

For what it's worth, I agree.

I think that the current "core" developers of D are exceptional programmers, with a very astute eye as to what makes a good programming language and the skills to implement it.

That said, the management of D is relatively poor.

For any programming language to make headway in the real world (i.e. not in the language aficionado's playground) it HAS to have some form of stable branch *. The documentation MUST be up to date and complete for that stable branch, including all the things that are wrong with it!

A path I see

1. Redirect current efforts towards stability **, aiming to produce a major release of DMD+druntime+phobos with complete and __honest__ documentation (i.e. admitting that something doesn't quite work right, "use at your own risk"). Then, make an aggressive push to get that stable release into use in mainstream, large-scale projects, which given D's power, combined with stability, should be much easier than before.

2. Someone takes on a significant managerial/admin position, who has responsibility over the documentation and stable releases of D. This would be a pretty unexciting job, so it probably needs to be paid in order to get it done well. After part 1, finding some money shouldn't be so hard.


My fear is that if the D rocket doesn't lift off now, it never really will.


* Look at python for example. Effectively the entire language is branched every so often and stabilised, including the standard library. Major release numbers signify a particular "branch", which is then pushed towards it's most stable state, while new features and significant code-breaking changes go in the next version number.

** Please note that I do NOT mean making the language work perfectly, fixing every bug. I mean fixing a lot of the low hanging fruit and properly documenting the problems that remain.

On Wednesday, 28 November 2012 at 14:34:12 UTC, John Colvin wrote:
> On Wednesday, 28 November 2012 at 13:15:26 UTC, Jacob Carlborg wrote:
>> On 2012-11-28 13:41, Walter Bright wrote:
>>
>>> On the other hand, many people were unhappy with my position of "no
>>> breaking changes at all outside of clear bug fixes" to D1, which also
>>> implied "no language enhancements". There were many enhancements to the
>>> code generation, new platforms, etc., and many CTFE improvements (which
>>> I more or less regarded as bug fixing). There were also no changes
>>> allowed that affected binary compatibility.
>>
>> Please, please try and understand. It's not breaking changes in it self that is the problem. It's how they're handled.
>>
>> 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.
>
> For what it's worth, I agree.
> blah blah blah

sorry, I mean to edit out the bit about D1.5 in Jacob's post, not sure I fully understand what that would mean enough to agree with it

On Wednesday, 28 November 2012 at 12:53:34 UTC, Walter Bright wrote:
> On 11/28/2012 11:34 P I come here on a regular basis to see if
> > the issues hampering soM, Max Samukha wrote:
>> I have a different concession.me long-overdue work that is important to me (and
>> arguably to the community) have been resolved. There has been great
>> progress thanks to Kenji Hara, Don and others but a couple of critical
>> issues still remain (like this one
>> http://d.puremagic.com/issues/show_bug.cgi?id=5380).
>
>
> That issue is marked as "normal", not critical. You can raise it to critical, but if you do, please add an explanation why. Ditto for any others you find critical.

From my and other people's experience, setting bug severity, voting for bugs etc. usually has no effect, so I stopped doing that long ago.

Raised the severity and added a rationale.

Walter Bright:

> 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.

I am OK with such ideas. Below there are some musings.

How do you want to call (release numbers) those two D2 versions (Stable-D and Development-D)? I prefer a simple Python-like numbering scheme, where the second digit denotes significant changes (every 6 months?) and the third digit (plus alpha, beta, rc1, rc2, rc3, ... suffixes) refers to bug fixes that don't break much code. I think such numbering scheme is also able to make D look a little more mature and a bit more "professional".

I also think it's a bad idea to create a "D3", at the moment. This means I suggest to eventually merge in the Stable-D all the changes of Development-D (unless testing of the Development version shows that it's better to abandon an idea in both D2 branches).

I suggest to release Development-D quite often, like every 20-35 days, if it's possible.

The presence of Development-D should allow for a more relaxed development, bug fixing and more. There are several things to fix. One of such possible changes is to remove the inliner from the D front-end (because ldc2 and gdc2 don't use it). Making the front-end a slimmer is good. There are other changes worth considering, like aligning D ABI and function calls (as other compilers refuse or can't do those things). LDC2 will be probably quite used on Windows64bit.

Patches for Development-D should work in both D2 versions, unless the changes are about features not yet present in Stable-D.

For simplicity I think the first thing to do to go toward the first Stable-D version should be strip away the D1 parts from the D2 Git sources, to clean and shorten the D2 code and make its updates simpler.

As others have said I think it's better to not keep a single Development-D trunk, but branch it when new features (or significant changes) are developed (like UDA).

Bye,
bearophile

On 2012-11-28 15:36, John Colvin wrote:

> sorry, I mean to edit out the bit about D1.5 in Jacob's post, not sure I
> fully understand what that would mean enough to agree with it

Just as with D1 now, it only receives bug fixes. But it would also receive new features which are backwards compatible. I.e. adding a completely new module to the standard library is backwards compatible change.

-- 
/Jacob Carlborg