On Fri, 13 Jul 2012 09:58:22 -0700, Jonathan M Davis <[email protected]>
wrote:
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.
And if we had a dev branch we could have rolled Object const into it and
let it broken there without affecting stable.
We have no stable release because we only have one branch, dev. To have a
stable release you must first have a branch you consider to be stable.
Major changes are rolled INTO stable from dev once they become stable.
Another term for stable is staging if that language helps you understand
the concept better.
Stable does NOT and NEVER will mean bug free.
It means that we think this code has generally been well tested and works
in most cases and we promise not to break it with big changes. Note the
last part, we promise not to break it with big changes (such as object
const). Thats how you create a stable release, first you must promise not
to break it severly. Currently we don't make that promise.
But just because we don't make that promise does not mean that we cannot
or should not make that promise. That promise is highly valuable to the
community at large.
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
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
