3 ms·
The biggest problem is with an ecosystem of libraries. I avoid libraries that depend on Google's Guava because one uses 21, another 24, another 23.5. There will
by dtech 8y ago
The biggest problem is with an ecosystem of libraries. I avoid libraries that depend on Google's Guava because one uses 21, another 24, another 23.5. There will maybe be a year between 21 and 25. All binary incompatible.
So you either need to stick to 1 version for the whole ecosystem or use tricks to give each library its own exact version of Guava it expects.
- AgentME 8y agoThat seems like a problem with Java or Maven: it doesn't allow multiple major versions of a library to co-exist within a project. NPM and I believe Cargo both allow this. There's cases where this isn't great (where multiple libraries each need to communicate with each other using a data structure implemented by another library, but they each depend on a different version of the data structure library, or where the library you have multiple versions of is gigantic; this might be a good argument for using many small and focused libraries instead of fewer big ones), but overall allowing multiple versions in one project can save a lot of needless headaches.
- dtech 8y agoThe NPM approach does not have that specific downside indeed, but like you said. What are you going to do when both return a different version of a Type to the "main" code? It's not a Java/Maven problem. Rubygems, Pip and Cabal have the same restriction, and that's only the ones I know that have it.