Hi Andreas, On Wed, 27 Jul 2016 18:19:18 +0200 Andreas Enge <[email protected]> wrote:
>It is our common practice to not re-encode the version into the name: Usually >the unnumbered name simply stands for the latest version That's unfortunate. I can live with it - but there is a reason the API major versions are usually encoded there. Otherwise it's not possible to ever make a clean API break and be safe with it. Just to make sure: I'm not saying the API major number should absolutely be part of the name, I'm saying there should be version bounds for all the inputs of packages. > In this way, updating dependencies becomes easier: Most of the time, a later > version of a dependency will work. Then there would have been no reason to update the API major number in the first place. Of course I can think of scenarios where it would work regardless - for example if the package used only a subset of the entire functionality, it could be that this subset is still compatible. Python 3 is an example - few Python 2 programs will work on Python 3 without changes - so it makes no sense to "autoupdate" a Python 2 package to a Python 3 interpreter in isolation. Of course, if you are lucky, you can find some subset where it happens to work by accident. When Python 4 is released, a similar argument can be made. >To follow your suggestion, we would ultimately add the soname of libraries to >package names, Only the part that is the API (in)compatibility version number - but yes. > and then whenever some package is updated, all packages depending on it would > need to have > their inputs rewritten. Hopefully after checking whether the new API actually still does the right thing for it... Thanks, good to know the common practice.
