Is one upshot of this is that we should base the version number based on this OSGi report tool?
Gary On Jun 11, 2017 1:58 PM, "Simon Spero" <sesunc...@gmail.com> wrote: > 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 >
