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). 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 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). 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. 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. 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
