D versionning

[Jonathan M Davis]

On Thursday, July 12, 2012 18:49:16 deadalnix wrote:
> The system adopted in PHP works with a 3 number version. The first
> number is used for major languages changes (for instance 4 > 5 imply
> passing object by reference when it was by copy before, 5 > 6 switched
> the whole thing to unicode).
> 
> The second number imply language changes, but either non breaking or
> very specific, rarely used stuff. For instance 5.2 > 5.3 added GC,
> closures and namespace which does not break code.
> 
> The last one is reserved for bug fixes. Several version are maintained
> at the same time (even if a large amount of code base is common, so bug
> fixes can be used for many version at the time).

You know, the more that I think about this, the less that I think that this 
idea buys us anything right now. This sort of versioning scheme is great when 
you need to maintain ABI compatibility, when you want to restrict adding new 
features to only specific releases, and when you want to specify which kind of 
release is allowed to introduce breaking changes, but it doesn't really fit 
where D is right now.

We're not at a point where we're trying to maintain ABI compatibility, so that 
doesn't matter, but the major reason that this wouldn't buy us much is that 
almost all breaking changes are not introduced by new features or major 
redesigns or whatnot. They're introduced by bug fixes (either by the fix 
themselves changing how things work, since the way they worked was broken - 
though code may have accidentally been relying on it - or because a regression 
was introduced as part of the fix). Once in a while, fleshing out a partially 
working feature breaks some stuff (generally causing regressions of some kind), 
but most of it's bug fixes, and if it's due to an incomplete feature being 
fleshed out, then fewer people are going to be relying on it anyway. The few 
new features that we've added since TDPL have not really been breaking 
changes. They've added new functionality on top of what we've already had.

The few cases where we _do_ introduce breaking changes on purpose, we do so 
via a deprecation path. We try and inform people (sometimes badly) that a 
feature is going to be changed, removed, or replaced - that it's been 
scheduled for deprecation. Later, we deprecate it, and even later, we remove 
it. In the case of Phobos, this is fairly well laid out, with things generally 
being scheduled for deprecation for about 6 months, and deprecated stuff 
sticking around for about 6 months before being removed. In the case of the 
compiler, it's less organized.

Features generally don't actually get deprecated for a long time after it's 
been decided that they'll be deprecated, and they stick around as deprecated 
for quite a while. Newer functionality which breaks code is introduced with -w 
(or in one case, with a whole new flag: -property) so that programmers have a 
chance to switch to it more slowly rather than breaking their code immediately 
when the next release occurs. Later, they'll become part of the normal build 
in many cases, but that generally takes forever. And we don't even add new 
stuff like that very often, so even if you always compile with -w, it should be 
fairly rare that your code breaks with a new release due to something like 
that being added to -w. The last one that I can think of was disallowing 
implicit fallthrough on case statements.

So, in general, when stuff breaks, it's on accident or because how things 
worked before was broken, and some code accidentally relied on the buggy 
behavior. Even removing opEquals, opCmp, toHash, and toString will be done in 
a way which minimizes (if not completely avoids) immediate breakage. People 
will need to change their code to work with the new scheme, but they won't 
have to do so immediately, because we'll find a way to introduce the changes 
such that they're phased in rather than immediately breaking everything.

All that being the case, I don't know what this proposal actually buys us. The 
very thing that causes the most breaking changes (bug fixes) is the thing that 
still occurs in every release.

- Jonathan M Davis