commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <garydgreg...@gmail.com>
Subject Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request
Date Wed, 07 Jun 2017 21:02:22 GMT
On Wed, Jun 7, 2017 at 10:28 AM, Simon Spero <sesuncedu@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
>

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