On Wed, Jun 7, 2017 at 10:28 AM, Simon Spero <sesunc...@gmail.com> wrote:
> 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. > We should run mvn verify anyway to pick up any other checks like integration tests. Gary > > 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 >
