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 Sun, 11 Jun 2017 19:16:58 GMT
My POV is that I only see a possible use cases for this in multi-module
components where one module defines an API and others different
implementation. Our release process is enough of a pain. Asking everyone to
consider if a change warrants a package version change is a pain. I still
do not see what practical and concrete problem this would solve for a
single module component. Granted COMPRESSA defines an API and
implementations all is one jar. But we work for 100% BC within a minor
release, so no problem there right? For BC breaks, we use a new version and
new package name, so no problem either, right?

Can you show us a real problem that this would have solved? If not, write
up a realistic imaginary problem?

Gary

On Jun 11, 2017 10:25 AM, "Simon Spero" <sesuncedu@gmail.com> wrote:

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 <garydgregory@gmail.com> wrote:

> 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