I'd love to have a semantic versioning plugin like that which can suggest what the version number is for the entire project. Elm (programming language) has a tool like that, and it works rather well in practice (even though there are some popular libraries that are at version 5.0.0 already because of it).
On 11 June 2017 at 18:37, Gary Gregory <garydgreg...@gmail.com> wrote: > 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 > > > -- Matt Sicker <boa...@gmail.com>
