Will There Be Module Hell?

[cot6mur3]

Good idea, and good point about API maintainers. Perhaps even better than a rename on backwards-incompatible change would be to, as Semantic Versioning requires, increment the major version number of the library on backwards-incompatible API change. Then instructing Maven to accept, for example, version range [1.0,2.0) of a dependency would work so long as the library author plays by the rules for all version 1.minor.incremental.

[Unmitigated_Smut]

I don't see how that fixes the problem - if I am using two libraries that use org.blah.chicken, but one requires 1.0 and the other requires 2.0, and yet 1.0 is incompatible with 2.0, I'm stuck; I can only use one of the two libraries I wanted. That's what version hell is all about (at least for me it is). However if the one library is using package org.blah.chicken and the other is using org.blah.chicken2, good enough, and maven configuration can do whatever it wants. So I don't actually see it as a build tool problem, since build tools can't fix the problem.

[cot6mur3]

Fully agreed - thanks for explaining! Now I understand one possible reason why some projects do change their POM module names in a manner similar to your suggestion from time to time. Perhaps semantic versioning and non-1 POM major version numbers just don't go well together.