And probably the most convincing argument to increase the minor version is: In a consumer bundle which relies on this new behaviour I want to require the right API and API Provider. If only macro would have been increased, I could not rely on that since the default version range for the Import-Packages statement only covers the same major and minor version as lower bound (it does consider neither macro nor qualifier) and therefore would be the same for the old and the new API (i.e. [2.2,3.0))
> Am 18.04.2016 um 18:29 schrieb Konrad Windszus <[email protected]>: > > I think according to semantic versioning > (https://www.osgi.org/wp-content/uploads/SemanticVersioning.pdf) > it requires an update of the minor version (as I have done). There it says: > ..... > minor — API consumers are compatible with exporters that have the same major > number and an equal or > higher minor version. API providers are compatible with exporters that have > the same major and minor > version number. For example, 1.2 is backward compatible with 1.1 for > consumers but for providers it is > incompatible. Consumers should therefore import [1.2,2) and providers should > import [1.2,1.3) > > In this case the API Provider is the "Scripting Core Bundle". So older > versions of the "Scripting Core Bundle" should not resolve with the newer API > bundle as the semantics (together with the JavaDoc) have been changed. Still > this change is backwards compatible from a consumers point of view. > > If we would not increase the minor version, the new API bundle would run > together with the old Scripting Core Bundle (API Provider), which is > incorrect, as the old provider does not fulfill the API contract of the new > API. > > Of course this would also require Scripting Core Bundle to depend on the most > recent API bundle (which I unfortunately forgot in my initial commit and > fixed now in https://svn.apache.org/r1739785). > > Konrad > > >> On 18 Apr 2016, at 15:22, Bertrand Delacretaz <[email protected]> wrote: >> >> Hi, >> >> In https://svn.apache.org/r1739719 Konrad incremented the >> org.apache.sling.api.scripting from 2.2.0 to 2.3.0 for SLING-5665 . >> >> That ticket introduces a minor semantic change in >> SlingScriptHelper.getServices(...), sorting the returned services >> based on their service ranking, with no binary API changes. >> >> It's just the semantics of the getServices method that change, in a >> backwards compatible way. >> >> I think we might just change the package version to 2.2.1, meaning "no >> backward compatibility issues" as per the OSGi semantic versioning >> recommendations. >> >> WDYT? >> >> -Bertrand >> >> (Currently this breaks a number of integration tests as the >> org.apache.sling.launchpad.test-services bundle is rebuilt with a >> version range of [2.3,3) and does not find that in the launchpad) >
