As Bertrand mentioned earlier, the bundle:baseline goal is built in to the maven-bundle-plugin already in use!
The pull-request adds that goal to the verify phase of the maven build (and changes the travis config to run 'mvn verify' instead of 'mvn test' ). The baseline goal is set to fail the build if the versioning contains errors. It takes very little work to bump the package version numbers when an API change is made. The first time you change a package in a way that requires a new version number, the build will simply break in the verify phase, with a list of changes, and a suggested new version number. Any further API changes to the package at the same level or below will pass the verify stage without a problem. For example, if you have already bumped the package by a minor version, any further minor changes won't require any more changes. However, a subsequent major (breaking) changes will fail when verifying. The author of the change can then consider whether the breaking change is the best way forward, or whether their goals can be achieved in different way.Studies have shown that there is considerable confusion about what is and isn't a binary compatible change in java (for example, changing the return type of a method from Collection<Foo> to List<Foo> is a binary-incompatible change (but is source-compatible). Breaking changes need careful consideration. In principle, the major and minor components of the bundle & artifact version should be bumped to match the most significant change in any package in the bundle/artifact, so that maven version-range dependencies don't break, but that ship has sunk. Simon p.s. The reason I'd been making changes to commons-compress was to support creating and using random access tar.xz files in order to store release series of bundles from maven-central to investigate this issue (and see how many problems can be fixed statically, and how many by dynamic rewriting and/or fibbing. p.p.s. Compressing series of maven artifact is quite interesting ; for example, the ten releases of common-math3 (to 3.6) contain 40.9 MiB of uncompressed contents: 17.8 MiB as jars. 6.4 MiB when the jars are packed in version order in .tar.xz format, 4.4 MiB if the jars are run through pack200 and xz'ed individually. 1.6 MiB if the compressed entries of the jar files are reflated first. 1.5 MiB if run through pack200 then tar.xz
