On Wednesday, 28 November 2012 at 13:31:36 UTC, Jacob Carlborg
wrote:
On 2012-11-28 13:46, Andrei Alexandrescu wrote:
Yep. Rails 4 breaks Rails 3 code. Not Rails 3.061 breaks Rails
3.060
code :o).
I've talked about that before. D doesn't have a versioning
scheme that makes any sense. It's just a number that gets
incremented without any meaning. Except that a greater number
indicates a later version. Also changes to the language,
compiler, runtime and standard library always happen in the
same release.
When people refer to D1, D2, D3, and eventually D4, etc, what
they should be referring to is a major version upgrade that will
purposefully contain breaking changes, and will inevitably
introduce a whole new set of bugs.
Usually increments to a minor version mean increasing stability,
not decreasing stability or unknown stability!
Major version increments means that breaking changes may be
introduced on purpose for a good reason, and it may mean new bugs
will be introduced as well.
The major/minor versioning system has been in use for ages. Many
people rely on it, including myself. I use different packages,
that I purposely keep at a certain major revision number, and I
always happily update to the next minor version, because it
introduces bug fixes, not breaking changes. I only migrate to the
next major revision only after it has matured over a few minor
increments.
Again, sometimes I jump on the next breaking major revision,
because it's for non-critical work, or for a new feature that I
really need today. The point is that I can identify what is
breaking and what is not just by looking at the version number,
and I can pick and choose which version I think fits the
stability model for my situation.
In any case, I did suggest re-thinking how a language can be made
to change in significant ways over time. The major.minor version
concept may be too simplistic for this, but holy crap, it's at
least a good start since we don't even have that!
Something has to change, and it has to change quickly.
--rt
