> On 27 May 2016, at 11:14, Oliver Lietz <apa...@oliverlietz.de> wrote: > > Upgrading a library bundle to a newer version does NOT break compatibility > with Sling's downstream systems. It is not like upgrading from Java 7 to 8 or > from Declarative Services 1.2 to 1.3. > > If you can deploy a newer version of a components/services bundle which runs > as singleton (e.g. HC Core) to an older system (e.g. AEM 6.1) you can easily > deploy a library bundle (whether you upgrade the older one or run both in > parallel). If you want to keep (for what ever reason) the older one and > deploying both in parallel does not work because of a limitation in OSGi > Installer, OSGi Installer should be improved. I really doubt this will ever happen, because it makes things a lot more complicated! My experience is different: I cannot easily upgrade the dependent 3rd party library bundle.
> > In my opinion we should always test our artifacts with current dependencies > (dependencies in Launchpad, a well known set). Older artifacts were already > tested with older dependencies. > > That is currently the case for org.apache.sling.launchpad.integration-tests > mostly. > > For unit tests and integration tests closer to the artifacts the setting is > different, e.g. use of Commons Lang in version 2.0, 2.2, 2.4, 2.5, 2.6, 3.0, > 3.0.1, 3.3.2 (similar for Commons IO, SLING-5685). > > So what's the point in testing with that outdated dependencies? > > I don't think there is support in Maven 3 for unit tests using a different > version than for compile. Not sure if other build tools can handle different > versions of dependencies for compile and test. > > So my preferred answers to eliminate outdated dependencies in tests: > > 1. use minimal version for compile and current version for test (how?) > 2. use current version for compile and test > 3. use current version for compile and test and carefully expand import range > > Not (never) upgrading dependencies (whether our own or 3rd party) may lead to > nasty or unnecessary code, see Konrad's commit: > > http://svn.apache.org/viewvc/sling/trunk/bundles/extensions/validation/core/src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java?r1=1740178&r2=1745478&pathrev=1745478&diff_format=h > > Why not upgrading Sling API to 2.7.0 (released two years ago) and use > resource.getValueMap() instead? > > When do we drop support for older systems? > > Regards, > O. >
