On Fri, 2016-05-27 at 09:55 +0200, Konrad Windszus wrote: > I understand and agree with 1. > For 2. I am not on the same page: > > Why should we run ITs with the most recent version instead of the > lowest required version?
IMO we should test with the version that is available in the launchpad - as that's what we "ship". Robert > IMHO we should confirm and validate with the IT that we can really > work with the lowest version of that dependency. > > I estimate the risk for regressions in a higher version much lower, > than the risk for facing a bug in the low version which prevents it > from working generally. > Konrad > > > > On 26 May 2016, at 18:06, Julian Sedding <[email protected]> > > wrote: > > > > +1 to Bertrand's summary. That matches my understanding of how > > we're > > dealing with 3rd party dependencies in Sling. > > > > 1. Keep the *required* version of a 3rd party library (an external > > API > > we depend upon) as low as easily practical. I.e. normally we don't > > work around bugs or missing new APIs in 3rd party libraries, but we > > don't raise the required version of the dependency just because it > > is > > available and thus artificially reducing the bundle's > > compatibility. > > > > 2. For tests or deployments (e.g. lauchpad), we aim to use the most > > recent version of the 3rd party dependency. As that is outside of a > > bundle's build, none of the Import-Package version ranges will be > > affected. > > > > This is a relatively simple way to create bundles with strongly > > compatible Import-Package version ranges. > > > > Regards > > Julian > > > > On Thu, May 26, 2016 at 2:46 PM, Konrad Windszus <[email protected]> > > wrote: > > > Hi, > > > > Am 26.05.2016 um 14:36 schrieb Bertrand Delacretaz <bdelacretaz > > > > @apache.org>: > > > > > > > > Hi, > > > > > > > > On Thu, May 26, 2016 at 10:21 AM, Konrad Windszus <konrad_w@gmx > > > > .de> wrote: > > > > > ...there was quite a discussion going on in https://issues.ap > > > > > ache.org/jira/browse/SLING-5603 on how > > > > > to deal with 3rd party dependencies in Sling.... > > > > > > > > My opinion, and I think this is what we've been doing in Sling > > > > forever > > > > even if we didn't explicitly document it, is that if a bundle B > > > > depends on another *for its API* then the dependency should > > > > list the > > > > lowest possible version. > > > What do you mean by its API? In SLING-5603 we were talking about > > > a dependency in the API Provider (Validation Core), not the API > > > bundle itself. > > > > > > > > > > > This makes B easier to use in many contexts, as long as the > > > > right > > > > version of the API, or a later one, is provided. > > > > > > > > > ...Another aspect of option a) is: With which version of the > > > > > dependency you want to run the IT.... > > > > > > > > This is the "recommented implementation" aspect of the > > > > dependency, > > > > which is a different concern. > > > > > > > > For this I suggest using the latest version of the > > > > implementation, or > > > > at least the one that we recommend. > > > If we don’t test with the minimum version we depend on (and which > > > determines the import-package version range) the risk for > > > depending on an non-working library version is IMHO much too > > > high. Therefore I would recommend to test with that minimum > > > version. Testing the recommended or latest version does give less > > > confidence that the bundle B really works with the lower version > > > of the dependency. > > > > > > > > > > > > > > -Bertrand > > > >
