I think that Ron has hit the nail on the head here, and what he says has become best practice, via many bruises, in the open source community.
Maven has a fundamental version model. That model is does not cover all possible real-world situations, as per JvZ's email and many others. In particular, it makes an assumption that all new versions are backward compatible. Here are some assertions you could imagine making in a POM that we can't make with Maven: * This project provides version 3.0 of XXX.YYY. It may be used to resolve dependencies that ask for [2.0-3.0). (And, implicitly, it may not be used to resolve a dependency on 1.0.) * This project provides version 3.0 of XXX.YYY. It may not be used to resolve any dependency on an older version, but it can co-exist in the namespace with older versions. * This project consumes version 3.0 of XXX.YYY. If dependency resolution tries to use some other version, fail unless the top-level pom explicitly has a marking to force this. * This project consumes version 5.4 of RRR.QQQ. If, somewhere in the dependency tree, SSS.TTT asks for AAA.BBB, override any restrictions on the version specified in SSS.TTT's pom. I know what I am doing. Since we can't make these assertions, Ron's scheme is the only possible scheme. If a new version is not strictly, provably, and completely, backward-compatible, you have to change the G/A or you are lighting the fuse on a ticking time bomb that will go off when the resolution algorithm cheerfully substitutes an incompatible newer version. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
