2015-11-29 22:03 GMT+01:00 Imants Cekusins <imantc@gmail.com>:

> In the exporting library? In the importing library?

Well, in both places. Basically, similar part of namespace guarantees that api is the same below.

To make this work on the exporting side, the namespace hierarchy would need to be structured according to API versions. This would mean constant reshuffling of modules in the hierarchy every time you make an API change. Furthermore, speaking from a more aesthetical point of view, names in the hierarchy should have some sensible semantic meaning and should not be littered with more or less random name suffixes.

[...] This exact same version would be pulled in alongside other versions of the same library, used in other parts of a large app.

This won't work when e.g.the libraries have a C part (unless you convince all people out there to use some kind consistent hierarchical naming scheme for C, too).

It may lead to code duplication and larger binaries however it would essentially give you a sandbox with very little effort.

Personally, I don't consider littering my code with version numbers as "little effort". Stuff like this should be specified outside of the source code IMHO.

Well, let's say I am working on a library. Tempting as it is to release the first draft, I'd first use this fresh library in a few places, catch some bugs, fix them, and then release.

Because this takes time, this library would see very few releases per year.

It would be less likely to cause multiple version conflict.

This contradicts the common "release early, release often" scheme of doing things, which has *many* advantages. And the number of releases is not relevant in itself, it's how often you change the API, which is a totally different matter. The longer you wait with releases, the higher the chance is that the next release has an incompatible API change, and your users won't get bug fixes without that API change, which won't make them especially happy.

Cheers,