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? 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 <jsedd...@gmail.com> 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 <konra...@gmx.de> wrote: >> Hi, >>> Am 26.05.2016 um 14:36 schrieb Bertrand Delacretaz <bdelacre...@apache.org>: >>> >>> Hi, >>> >>> On Thu, May 26, 2016 at 10:21 AM, Konrad Windszus <konra...@gmx.de> wrote: >>>> ...there was quite a discussion going on in >>>> https://issues.apache.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 >>
