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