commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Spero <>
Subject Re: OSGI Version at Package Level : some more details about the COMPRESS-399 pull request
Date Sun, 11 Jun 2017 20:58:15 GMT
On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory <>

> 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?

See: e.g

Note that the specific versions of *org.apache.commons.fileupload *are not
completely on point, since as far as I know the first version of
commons-fileupload to include bundle headers was 1.2.1

However, we don't have to go much further to find more examples in that
The bundles org.apache.commons.fileupload , version 1.2.*1*, and
 org.apache.commons.fileupload, version 1.2.*2*  use the  same  version
numbers for all packages, are two *micro* (aka bug-fix) version numbers
within the same micro version.  Under  semantic versioning rules, micro
versions must not have any API changes.

However, between those 1.2.1 and 1.2.2, there are *minor* level changes to
two of the five packages (the other three remain unchanged.
Moving from version 1.2.2 to version 1.3.0,  there are *major* breaking
binary changes to four packages (meaning they should have version 2.0.0).
>From version 1.3.0 to 1.3.1 there are minor (backwards compatible changes)
to one package, with the other four having no API changes.
>From 1.3.1 to 1.3.2 has no API changes, so is the micro version bump is

 Looking at commons-math, there were major breaking changes to 6 packages
between versions  2.0 and 2.1.
There were five more packages with major level changes between 2.1 and
2.2.  This was the second set of breaking changes for three of  of these
packages; their correct version number should have been 4.0.   Note that
this is *before* the packages prefix got changes to org.apache.commons.math3

The nature of the major changes in commons-math (mostly changing the return
types of methods) suggests that the developers might have used a different
approach rather than breaking binary compatibility.  To me, it seems that
automatically bumping the major version would have been the wrong response.

If you like, I can post a list of what the package version should have
been, assuming that every compatibility change was intentional, and
versioning was properly applied,  for  every bundle series under
org.apache.commons and commons-* that was on maven-central as of mid-may?


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