Release process and backwards compatibility

[Jesse Phillips]

On Friday, 8 March 2013 at 20:07:50 UTC, Dicebot wrote:
> Now that http://wiki.dlang.org/Release_Process is slowly 
> adopted I want to rise this discussion again.
>
> Two somewhat contradictory aims meet here, both frequently 
> raised in IRC and newsgroup:
>
> 1) Breaking user code with release is incredibly painful and 
> brings lot of dissatisfaction.
> 2) Language specification is not mature enough yet and it will 
> need to be changed at some point unless we want to stay with 
> same design issues forever (D3 is forever enough).

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.

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.

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.