Hi, On 5 October 2017 at 14:16, Julian Reschke <[email protected]> wrote:
> On 2017-10-05 14:33, Ian Boston wrote: > >> Hi, >> Currently the whole Oak source tree is synchronously versioned. Which is >> great for Oak and its releases, but problematic downstream. I assume this >> has been discussed before, and hope it can be discussed again ? >> >> ------ >> >> If it can, here is some supporting evidence, using Sling as an example.If >> it cant be discussed and the case is closed, the please ignore this >> thread. >> >> Currently: >> When a version of Sling depends on Oak 1.6, 1.4 or 1.2 , and needs a >> feature or an API from Oak 1.8-SNAPSHOT, that feature or API must be >> backported and released to 1.6, 1.4 or 1.2, but probably all versions back >> to the one desired. >> ... >> > > Wait. > > Why would a new release of Sling *ever* reference an Oak version older > than the latest stable version? > Sling does modular releases. It can release Servlet Get 2.13.2 with a new feature and it doesn't have to release all the other bundles. Servlets Get 2.13.2 may have referenced a package of Oaks at version 1.0.0 in Oak 1.2, but since the current version of Oak 1.6.5 contains that package at 1.1.0 Servlets Get can still release using a reference to Oak 1.2 provided it deploys a bundle form Oak compatible with the current Oak server. If it was an API bundle, that might be an Oak 1.2.x bundle (I know, its not because Sling knows Oak does non modular releases and so uses oak.version everywhere to keep all in step). Bundle version != package version and compile, test, runtime depends on package version only. Did that make sense ? An OSGi expert might be able to explain it better. > > (I understand that this doesn't address the part about getting something > into the latest stable release, but AFAICT it simplifies your problem > statement). > Yes, it does for releases from Sling Trunk eg. The current stable version of Oak is 1.6.x So before Sling can move forwards it has to A: have 1.8-SNAPSHOT released to a stable version or B: Bind to an unstable version (eg 1.7.x) or C: Have Oak backport every feature that requires a change in Oak to 1.6.x A and C are more work for Oak. B, well, B isn't stable so Sling can't release binding to that. Releases from a maintenance branch of Sling are as per my overly complex problem statement. Best Regards Ian > > Best regards, Julian >
