> On Feb 22, 2017, at 11:23 AM, Raymond Auge <[email protected]> wrote: > Some issues are visible in this baseline report (look for instance of > MAJOR): > > https://gist.github.com/rotty3000/051db70089947914205a62f210b3be87
And how did ANY of that affect your application? That’s the point. Looking through that entire list, there is exactly one thing that could potentially have required a version update: Removal of Message.setContextualProperty - however, this method was not meant to ever be exposed and was completely broken in 3.0.x. It would not have done what anyone would have expected and, more important, any property set via this method would have potentially bean lost on a context recalc. Everything else in your report is non-User stuff and thus is not an issue. So basically it’s just a removal of a single method that didn’t work and shouldn’t have been exposed to the user or called by them. Not a “4.0” change. Dan > > Sincerely, > - Ray > > On Wed, Feb 22, 2017 at 10:48 AM, Daniel Kulp <[email protected]> wrote: > >> >>> On Feb 21, 2017, at 11:53 AM, Raymond Auge <[email protected]> >> wrote: >>> >>> Hello everyone, >>> >>> This is my first post to the list. So thank you in advance for all your >>> hard work and very good product. >>> >>> However, I have a question about semantic versioning of CXF. >>> >>> In our project we are using CXF (piecemeal). >>> >>> However when we upgraded our dependency from 3.0.3 to 3.1.9 we >> encountered >>> MAJOR api changes while baselining. >> >> What kind of major changes? User code should rebuild/re-compile without >> problem when moving from 3.0.x to 3.1.x. >> >> >>> It seems that there are many semantically invalid changes on this >> apparent >>> _minor_ release. I wondered if the CXF project knows that some changes >> are >>> not semantically correct or was simply an oversight? >>> >>> Would the CXF project entertain adding baseline checks to the build to >>> assert semantic versioning? >> >> Probably not. The semantic versioning that we care about is if apps >> written to JAX-WS and/or JAX-RS and use the “normal” configuration >> mechanisms (spring/blueprint) will re-compile and run without >> modification. Any API changes within CXF modules or between them is not >> something we worry about. >> >> -- >> Daniel Kulp >> [email protected] - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance) -- Daniel Kulp [email protected] - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
