Thoughts on versioning
Adam D Ruppe
destructionator at gmail.com
Thu Oct 28 14:01:57 UTC 2021
On Thursday, 28 October 2021 at 13:34:14 UTC, Ola Fosheim Grøstad
> "can" is one thing, but can you do it in a way with that is
No, but I also don't think that matters. You need to pick a new
version so then you expect things to be different.
There's always problems. You need to pick which ones you care
about. There's two things to think about:
1) the hassle of updating with breaking changes
2) the incompatibility of diamond dependencies
A diamond dependency is when your app depends on libA which
depends on thingv1 and also on libB which depends on thingv2.
For #1, I'd just really provide a migration path. If it is too
much of a pain, version lock what you already have. But you'll
probably lead to a diamond dependency eventually anyway as not
Let's look at some solutions.
With dub's version scheme, this is an error. When it detects
this, dub stops building.
With the SAOC mangling scheme proposal, you're liable to have
runtime crashes when you import one version of a type yet pass it
to a library that needs another version - ABI mismatch beyond
what mangles can see. The idea to add type layout to the mangle
would turn this from a runtime crash into linker error, but it
Moving the version difference up to the module level is liable to
create compile errors of the type "cannot pass X to function
expecting argument X" (where X is v1 in one case and v2 in the
other case). You can actually solve this with a runtime
conversion, or making the compatibility layer check or whatever.
It won't "just work" but since it is manageable it is my
But then changing versions means updating imports to opt into
it... which again i say "meh" but some people can't stand. It
also means potential duplication which can be a hassle but again
it is something you can manage so again "meh".
And sure maybe you can detect a change in the compatibility layer
with reflection. Maybe some types won't convert back and forth.
But... so be it. My view is a compatibility layer is to bridge
the gap between the inevitable migration. Again, for an
individual, you can just version lock. It is really only the
diamond problem that is blocked.... and there, if they don't
migrate eventually it will just get worse anyway, but they might
not all migrate at the same time.
And if a lib never updates and it is hard incompatible the whole
time? Just use a better lib.
More information about the Digitalmars-d