On Wednesday, 5 September 2018 at 04:32:18 UTC, SrMordred wrote:
Wouldn´t be interesting to specify the compiler version on
dub.json?
(I think ruby uses this idea)
Ruby 1.8 stuck around for four years before Ruby 1.9 came out.
Then it was six years until Ruby 2.0 came out. These days,
there's an annual release, but the magnitude of changes is also
pretty small.
Compare with DMD over the past year. (Just one year!) opDot was
deprecated, C-style array declarations were removed, opDispatch
works differently with `with` statements, arithmetic with
pointers of different types was deprecated, comma expressions no
longer yield a value, `delete` was deprecated, hex string
literals were deprecated, class allocators were deprecated,
certain types of postblit operators were deprecated, some
operations on `shared` variables were deprecated, declarations in
switch-case statements can't be used in other case blocks
anymore, `catch` statements have to declare something they catch
now, you can't compare values from different enum types anymore...
That's not all the breaking language changes in the past year.
And it's just one year. (I'm cheating a bit by counting both
deprecations and lapsed deprecation periods, but still.)
D can't use semantic versioning because nearly every release has
breaking changes. Most of them won't affect your code in
particular, but once you start using a bunch of libraries, it's
going to be painful.
So how does this work with your library and depending on a
specific range of language versions? You test with whatever
compiler you normally use, and if you're super conscientious, you
might test out a few other versions. So in order to stay
up-to-date with new compiler releases, you need to re-test your
library, update the supported-versions flag, and tag a new
release every time there's a compiler change.
Fortunately, this can be automated, as long as you have automated
testing.
