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?

Reply via email to