commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Spero <sesunc...@gmail.com>
Subject OSGI Version at Package Level : some more details about the COMPRESS-399 pull request
Date Wed, 07 Jun 2017 17:28:03 GMT
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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message