Release process and backwards compatibility

Dicebot m.strashun at gmail.com
Fri Mar 8 12:07:49 PST 2013


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).

As far as I see it, both points have a quite wide support in the 
community.

It is important to note that when I speak of breaking code and 
language changes, I mean ALL changes. Currently weird hypocrisy 
has place when bug fixes that involve changing language semantics 
are not considered to be backwards-incompatible and this actually 
every release breaks code in practice. As dmd front-end IS the 
specification currently, there is no way for user to know if 
certain behavior is bug or feature thus any semantics change must 
be considered breaking change.

That is it, now we are in position when we both need to change 
stuff and can't. Every time this issue reappears, new hacks and 
workarounds are introduced without addressing it in general. I 
think this can be solved via some strict additions to the release 
process.

I'd gladly hear any proposals on topic, but here is mine:

Currently bug fixes go only to last major version branches. 
Considering how fast major version changes (and that we don't 
have minor versions in practice) that is hardly different from 
fixing only one branch. This is what makes 
backwards-compatibility problem that unpleasant - there are no 
versions of compiler user can stick to for a longer time period 
with hard 100% guarantees no semantics change will happen, 
receiving non-breaking fixes at the same time. There are no LTS 
releases. I think adding ones will allow to remove breaking 
change ban from master and allow continuous improvement of 
language design with no hard consequences for real-world users.

By LTS I mean certain announced version that gets back-ported all 
bug fixes that does not introduce any semantics change. To be 
usable in practice I thing those need to be released once a year 
with two LTS releases supported at time. Announcing, both via 
dlang.org and D.announce, is important here. That will require 
considerable efforts and may slow down development on master but 
at least it is step aside from current stalemate.

Opinions/proposals?


More information about the Digitalmars-d mailing list