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 23:37:11 GMT
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" <sesuncedu@gmail.com> wrote:

> On Sun, Jun 11, 2017 at 3:16 PM, Gary Gregory <garydgregory@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
>

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