On Saturday, 9 March 2013 at 07:19:34 UTC, Dicebot wrote:
Any well-thought change is the way forwards as it improves the language. And is actually a regression.
I disagree with your definition of regression and prefer: "A return to a former or less developed state."
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.
I'm not talking hypothetical here, my experience. Update opEquals and toHash so they are const/pure/nothrow/fairy dust I'll grumble as I now need to update code I didn't write so don't understand the ramifications of my changes, but so be it. But to have to change it all back the next release because it was too disruptive and there might be a different approach that needs taken, that brings grumbling to a whole new level. (I'm not as annoyed as I make it sound, but I certainly am not sounding annoyed enough for many)
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.
And that is what it comes down to, how do we do it. The Utopia, all non-breaking changes are applied to all past releases. We need a middle ground, somewhere probably not near the middle. And gave my approach.
This is already accepted as part of new release process, but, unfortunately, does not seem to be executed in practice.
Shouldn't we be trying to get this practiced first? Your suggestion still relies on maintaining something other than the current dev branch. If we can't get this, what are we left with?
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.
You can remain on the same compiler version you initially programmed for. I'm all for a Long term support like approach, but I see that as a secondary thing to properly releasing a dev.
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.
A Long Term Support does not allow for more breaking changes, it only delays how long before you have to deal with it. There are only two options to not have breaking changes, the C++/Windows approach (which fails) and never updating your program. But we can do a better job managing expectations.
