Release process and backwards compatibility

[Dicebot]

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.