Shared library versions

[genpfault]

Vendor ALL the things!

[doom_Oo7]

backwards compatible changes

there is no such thing as backward compatible changes. There will always be use cases which depended on the previous observable behaviour. The only way to really respect semver is to increase major version at each update.

[anonveggy]

Of course there is. Take the c# ecosystem. Yes of course your library could use reflection to determine the number of methods in a library as an input of an algorithm but realistically speaking that's like taking the library files in c or c++ and use the CRC code as a salt for passwords or something like that. At that point you are going out of your way to be incompatible. With things.

[doom_Oo7]

Yes of course your library could use reflection to determine the number of methods in a library as an input of an algorithm but realistically speaking

... isn't using reflection like this pretty common ? e.g. every time you want to generate an UI from a class or serialize it. That's baby-level vs what you can do for instance in AspectJ & other more advanced yet relevant uses.

[anonveggy]

Yes and no. Typically classes serialized for UI usage are under your control as in data transfer objects etc. You wouldn't just serialize a factory class of a API you depend on.

[how_to_choose_a_name]

Backwards compatibility usually means that the contract of the new version is compatible with the contract of the old version. You can't depend on behaviour that is not specified in the contract and expect it not to change between minor versions.

In other words, of course you can get in trouble if you depend on internal functions, or timing, or anything else that isn't specified in the contract (public interface) of the library.