On 20 February 2015 at 01:23, Stian Soiland-Reyes <st...@apache.org> wrote: > On 19 February 2015 at 18:47, sebb <seb...@gmail.com> wrote: >> Not necessarily, my example was about requiring a major bump in JVM version. >> Still binary compatible, but might require users to upgrade their host JVM. >> Therefore it may be worth flagging the change to end-users via the >> version number. > > Agreed that in Commons could be a good example for bumping major > without changing the package name, although generally speaking "change > of dependency requirements" would be a minor change. > > >> AFAIK Maven does not do that. > > No (but perhaps it should).
I disagree that it should. > Maven's understanding of "1.5" without any ranges will also cover > "2.1" - which by SemVer is risky business (perhaps your favourite > public method has been deleted), although with the Commons versioning > practice, it should still generally "just work" if a Commons module > changed major without binary incompatibility (e.g. for JVM example) > and thus didn't rename. > Maven relies on the group/artifact ids to determine whether jars are allowed to co-exist on the classpath or not. Maven does not allow two jars with the same gid/aid to co-exist on the classpath; at most one is chosen, based on version comparison. Maven treats jars with distinct gid/aid as different jars, so they can co-exist. > Maven 3 will honour a range like [1.3,2.0) (which should be the > SemVer-safe way to depend on 1.3.x but avoiding 2.0.0 and above). Maven does not care about SemVer; it only cares about the gid/aid. Provided that the gid/aid is correctly specified there is no need to mess around with versions as well. > If a dependency with such a range is combined with another dependency > that pulls in a at first look conflicting version, say "2.1", then as > "2.1" is a not a range, it is a "soft requirement" with no min or max, > thus say 1.5 would satisfy both dependencies. > > http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges > > > Depending on the change and usage this might or might not work at > compile and/or runtime. For instance, if you have a Java interface > that renames a method, that is clearly a new major version (and new > artifact within Commons) - yet (without such ranges) Maven will > happily let you use an older implementation that does not implement > the method that you are calling - the error is not apparent until > runtime. That is why Commons changes Maven coords and package name when breaking binary compat. > > If you have two incompatible ranges, say "2.1" is changed to [2.1,) - > then you get error from Maven 3: > > [ERROR] Failed to execute goal on project user: Could not resolve > dependencies for project org.example.user:user:jar:0.0.1-SNAPSHOT: > Failed to collect dependencies for > org.example.user:user:jar:0.0.1-SNAPSHOT: Could not resolve version > conflict among [com.example.api:example-api:jar:[2.0.0,), > com.example.impl:example-impl:jar:2.3.0 -> > com.example.api:example-api:jar:[1.0,2.0)] -> [Help 1] > > > > > > >> What is the evidence that a major bump causes warnings? > > See above. No, that does not prove the case. It only proves that major bumps can cause issues with version ranges, which is rather different, and depends on the exact ranges that are used. > Note that a quick grep in my big .m2/repository didn't reveal any > dependencies on commons* that used ranges - probably because of > Commons being good in not breaking stuff. :) > > > > > > -- > Stian Soiland-Reyes > Apache Taverna (incubating) > http://orcid.org/0000-0001-9842-9718 > > --------------------------------------------------------------------- > 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
