So what's the current thinking on using compatibility-verified package versioning (for commons-* in general, but COMPRESS-399 in particular?)
It doesn't take much work, and incorrect package versions cause real problems. *You added the headers and here I am. You tell 'em I'M coming... and Jar Hell's coming with me, you hear? **Jar Hell's coming with me!* Simon On Wed, Jun 7, 2017 at 5:02 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > 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 > > >
