On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory <garydgreg...@gmail.com> wrote:
> 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 http://www.sciencedirect.com/science/article/pii/S1571066111000399 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 series. 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 correct. 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? Simon
