Thoughts on versioning

[Adam D Ruppe]

On Thursday, 28 October 2021 at 13:34:14 UTC, Ola Fosheim Grøstad 
wrote:
> "can" is one thing, but can you do it in a way with that is 
> undetectable?

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 
everyone locks.

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 
still fails.

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 
preference.

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.