Dependency management does not cure this if C 1.2 and C 2.0 are not binary compatible. Code compiled with the 1.2 version will fail if those methods and classes are not in 2.0.
Ralph > On Jun 2, 2016, at 3:03 PM, Benson Margulies <bimargul...@gmail.com> wrote: > > Dependency management cures this; if you don't want to pick up newer > versions, you can prevent it. Since dep management doesn't know about > ranges or semantic versioning, you need to then pay attention if you > want a compatible version that comes along. > > I guess it's a question of which poison you prefer. If people here > prefer bumping artifactids and package names, so be it. > > > On Thu, Jun 2, 2016 at 6:01 PM, Benedikt Ritter <brit...@apache.org> wrote: >> Hello Benson, >> >> Benson Margulies <bimargul...@gmail.com> schrieb am Do., 2. Juni 2016 um >> 23:36 Uhr: >> >>> I don't understand what's wrong with semantic versioning and keeping >>> the same maven coordinates. No sane person should be using RELEASE or >>> LATEST. >>> >> >> The problem are transitive dependencies. Consider this example: >> >> My-Project >> | -> A -> B -> C 1.2 >> | -> D -> C 2.0 >> >> In this case my project depends directly on A and D. A depends on B which >> depends on C in version 1.2. D depends on C in version 2.0. In this case I >> have no control over the dependencies to C but my project will be broken at >> run time, because C 1.2 and C 2.0 can not exist at once in the same >> classpath. >> >> Benedikt >> >> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
