Release process and backwards compatibility

[Jesse Phillips]

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.