On Saturday, 9 March 2013 at 04:55:06 UTC, deadalnix wrote:
> This isn't the type of change you can release without any damage mitigation plan.

Don't leave us hanging. What is your damage mitigation plan?

My desire is made elsewhere, but I don't think there is anything to do, code will break, instead dmd 2.062.1 should get released and contain regression and non-breaking bug fixes.

On Saturday, 9 March 2013 at 03:38:13 UTC, Rikki Cattermole wrote:
> How ever this will bring back e.g. the old python 2.x vs 3.x divide which would be a shame. But at the same time it'll mean we can do some big stuff that would just not be acceptable in breaking old projects.

We don't need to go all the way over to a different language to learn from the past. We beat Python to it with D1. I don't think that was a mistake, but I think it would be now.

On Saturday, 9 March 2013 at 05:11:40 UTC, Jesse Phillips wrote:
> On Saturday, 9 March 2013 at 04:55:06 UTC, deadalnix wrote:
>> This isn't the type of change you can release without any damage mitigation plan.
>
> Don't leave us hanging. What is your damage mitigation plan?
>

I feel like a parot having to repeat the same shit again and again and again. So I wont, I expanded myself on such topic so many time already.

See how PHP handled the transition from 4 to 5 for a good example of how it can be done.

On Saturday, 9 March 2013 at 05:15:12 UTC, deadalnix wrote:
> I feel like a parot having to repeat the same shit again and again and again. So I wont, I expanded myself on such topic so many time already.
>
> See how PHP handled the transition from 4 to 5 for a good example of how it can be done.

No, I'm not asking about improving the release process, I'm asking how do you mitigate damage done by this specific change. You can give people a compiler with some non-breaking updates to delay the inevitable, but if they take this change what needs to be done to make the transition easier?

On Saturday, 9 March 2013 at 06:07:12 UTC, Jesse Phillips wrote:
> On Saturday, 9 March 2013 at 05:15:12 UTC, deadalnix wrote:
>> I feel like a parot having to repeat the same shit again and again and again. So I wont, I expanded myself on such topic so many time already.
>>
>> See how PHP handled the transition from 4 to 5 for a good example of how it can be done.
>
> No, I'm not asking about improving the release process, I'm asking how do you mitigate damage done by this specific change. You can give people a compiler with some non-breaking updates to delay the inevitable, but if they take this change what needs to be done to make the transition easier?

Many things can be done to mitigate that stuff.

The first, obvious one, is to provide a version of the compiler without the fix (bug with other fixes that don't break most code).

A second thing to do is to adapt phobos to take rvalues at several places. (This have the problem that ranges have unspecified behavior when passed by value).

Finally, an useful error message, with a workaround proposal would be welcome,
Error, range used as lvalue. You may want to do BLAH to solve that.

On Friday, 8 March 2013 at 20:33:20 UTC, Marco Leise wrote:
> I don't know much about the development process, but as you
> said some bugs may be features or vice versa. Sometimes real
> bugs are fixed and peoples' code breaks. But keeping the bug
> around isn't an option.
> The next code breakage comes from making array slices
> consistently rvalues (the slice structure itself, not the
> data). It's not a new idea, like introducing immutable, just
> wasn't correctly implemented from the start. I don't know if
> this warrants a LTS release already. The problem will be
> obvious and easy to fix by introducing a temp variable to pass
> as lvalue into functions taking slices by ref. Or changing
> those functions to auto-ref.

LTS release should be something time-based, not feature based. It is not that important what exactly goes there if it is guaranteed to have support for some long time.

Your post reminds me of another idea though - it could have been a good attitude to have a separate "breaking changes/fixes" block in change log and, probably, announce those upon merged pull request before release is even made. One of least pleasant qualities of breaking bug fixes is that they are discussed in github mostly and come in a form of surprise upon release.

On Saturday, 9 March 2013 at 05:11:40 UTC, Jesse Phillips wrote:
> On Saturday, 9 March 2013 at 04:55:06 UTC, deadalnix wrote:
>> This isn't the type of change you can release without any damage mitigation plan.
>
> Don't leave us hanging. What is your damage mitigation plan?
>
> My desire is made elsewhere, but I don't think there is anything to do, code will break, instead dmd 2.062.1 should get released and contain regression and non-breaking bug fixes.

As deadalnix have said (and I fully agree here), "The problem isn't really breaking the code. It is more about how it is done.". Thus, proper announcements and release model change actually is damage mitigation plan. Not really an excellent one, but better than having none currently.

I am in "changes are good" camp, too. The very reason that made me start this thread is that many good proposals in DIP's where rejected because they break the code while it breaks in practice anyway. It is simply not possible to have one product that suits perfectly two conflicting needs.

On Saturday, 9 March 2013 at 05:05:42 UTC, Jesse Phillips wrote:
> When a bug in the language design or compiler/libraries is fixed; the changes needed to upgrade aren't nearly as draining because it is the way forward. It is where the language should be going. But hitting a regression, waiting for the next release in hopes that a new regression won't crop up (I'm just assuming compiler is released with all known regressions completed) is detrimental to expectations. Updating code to match the "new" way just to have it reverted the next week (in git, thus no release); those things are what really kill the idea of stability.

Any well-thought change is the way forwards as it improves the language. And is actually a regression. You tend to separate "good regressions" and "bad regressions" but there is no possible way to separate those unless you are deep into D development. We have no spec (reference compiler is the spec) and for an end user all those break code equally surprisingly, having good intentions does not help.

And clearly because changes are _needed_ and bug-fixing can't be stopped, there needs to be clear accepted approach of "how do we break stuff" instead of "breaking stuff is bad". I have attempted to suggest one such approach.

> So I would hope that a release is maintained until the next release. Regression and non-breaking bug fixes get applied to the release branch and are either released before the next release or at the same time. The point being that whatever issue was found was hopefully fixed and likely nothing new will be in the way to upgrade. A more elaborate system is fine, but I believe this truly the issues that need addressed first.

This is already accepted as part of new release process, but, unfortunately, does not seem to be executed in practice. Problem with maintaining only last 2 releases is that they come out pretty fast, sometimes as fast as once in two months. That does not leave enough time to adapt without sacrificing mundane development.

> As for those who want no breaking changes, don't update your compiler or pay DigitalMars to maintain it. D will get to a point breaking changes aren't so frequent. But right now we have issue that must go.

It is actually the other way around - I want _more_ breaking changes :) And that won't happen while two conflicting goals are pursued at the same time.

D3 would imply language changes of D1->D2 scale, adding new paradigm at the very least. Otherwise,
1) it will ne a surprise
2) given amount of breaking changes/fixes, we will be in D42 pretty soon
I don't think D3 can be even considered for that, it is all about making D2 mature, after all.