Hi, I’m curious to explore the reasoning behind the general principle of only having dependencies on stable Oak releases. Of course I understand the importance of keeping the codebase on a solid foundation and thus to want stable releases for dependencies. My question is, what exactly is meant by “stable”?
I expect we regard even-numbered minor versions in Oak as stable releases because that’s how the Oak project refers to such releases. Based on that reasoning, Oak 1.7.8 is unstable by definition. I’d then argue that if Oak were to change their versioning model (which I’m not proposing - and I wouldn’t propose it here if I was proposing such a thing anyway) such that a “stable” Oak release is defined by some other means (say, any version that passes the entire test suite), Oak 1.7.10 may be considered stable - in which case the concern to rely on that version would be lower. In other words: If Oak were to declare a version as stable, is that sufficient for us to rely on those package versions? Or would we do our own validation anyway? My point is that it appears the resistance to use a particular Oak version is based on Oak not declaring it as stable. Yet Sling probably depends on other packages that have different criteria for being considered stable - some which may not even declare a particular version as such. I don’t have concrete knowledge about that of course, just a hunch. But if that’s the case, perhaps it is worthwhile to consider the reason this policy was adopted for Oak packages, and maybe in understanding what the real goal is we can find a way where we don’t feel concerned updating dependencies to an “unstable” Oak release. For example, if such a release passes all Oak tests and all Sling tests, maybe that’s acceptable. -MR On October 12, 2017 at 8:34:50 AM, Ian Boston (i...@tfd.co.uk) wrote: Hi, Here is a patch to make Sling work with Oak 1.7.8. Once I fixed a full build (just did a pull request) it passes a full IT build. The patch updates the paxexam setup so IT tests that uses that will test against Oak 1.7.8. I also tested with 1.8-SNAPSHOT so this should be good for anything after 1.7.8. We might wait till 1.7.10 comes out as IIUC this will include OAK-6575. wdyt, mege when 1.7.10 is out and upgrade to a stable 1.8 when its cut ? Best Regards Ian 1 https://github.com/apache/sling/compare/trunk...ieb:upgradeToOak178?expand=1 On 11 October 2017 at 11:38, Ian Boston <i...@tfd.co.uk> wrote: > > > On 11 October 2017 at 11:25, Robert Munteanu <romb...@apache.org> wrote: > >> On Wed, 2017-10-11 at 11:16 +0100, Ian Boston wrote: >> > Hi, >> > Switching to depend on Oak 1.7 requires upgrading oak-server to use >> > 1.7 or >> > later. >> > There has been some incompatible changes at a bundle level and >> > package >> > level between 1.6 and 1.7 so its not as simple has changing the >> > versions. >> > For instance oak-api bundle didnt existi in 1.6 and NodeAggregator >> > class >> > doesn't appear to exist in 1.7. oak-server wont build without a >> > patch. >> > >> > Obviously, if you have an oak-server or equivalent that already >> > depends on >> > 1.7 or later, then its trivial, but Sling doesn't. >> >> So we need need to make oak-server and jcr.resource dependent on Oak >> 1.7, right? >> > > Yes, working on a patch now. > Compiles but all ITs fail. > > >> >> I would guess that oak-server is not such a big issue. Is it possible >> to make the dependency from jcr.resource to the newer oak api optional? >> If the bundle would also run on Oak 1.6 I guess there would be no >> issue. >> > > > In the original patch with AdapterFactories that would have been simple as > it was very loosly coupled for exactly this reason, however that patch was > rejected by this list, and a much more tightly bound patch[1] was > required. Making HelperData, core to Sling GET Servlets, load safely with > one of its imports optional will be messy and will make its method calls > nasty. > > Best Regards > Ian > > 1 https://github.com/apache/sling/compare/trunk...ieb:OAK-6575-3-2 > > > >> >> Thanks, >> >> Robert >> >> > Best Regards >> > Ian >> > >> > On 11 October 2017 at 11:07, Stefan Egli <stefane...@apache.org> >> > wrote: >> > >> > > Having said that, the only bullet to bite when switching to Oak >> > > 1.7.x is >> > > increased maintenance effort: the affected bundles will become >> > > backwards >> > > incompatible wrt Oak 1.6.x and if they need to be patched it would >> > > not be >> > > possible to do so in trunk anymore. >> > > >> > > Cheers, >> > > Stefan >> > > >> > > On 11/10/17 12:03, "Stefan Egli" <stefane...@apache.org> wrote: >> > > >> > > > Hi Ian, >> > > > >> > > > I don't see a problem with having a dependency on an unstable Oak >> > > > 1.7.x in >> > > > Sling. >> > > > >> > > > Actual deployments can still, independent of this, make a call >> > > > whether or >> > > > not they want to actually run on Oak 1.7.x or wait for Oak 1.8 >> > > > (which is >> > > > advisable). IMO having this dependency doesn't imply on which >> > > > version it >> > > > will ultimately run. >> > > > >> > > > Cheers, >> > > > Stefan >> > > > >> > > > On 11/10/17 11:54, "Ian Boston" <ianbos...@gmail.com on behalf of >> > > > i...@tfd.co.uk> wrote: >> > > > >> > > > > Hi, >> > > > > Oak 1.7.x is Oak unstable release branch working towards 1.8. >> > > > > I have a feature in SLING-7140 that is blocked by an API change >> > > > > in Oak >> > > > > present in 1.8-SNAPSHOT and available as an unmerged but tested >> > > > > patch to >> > > > > Oak 1.6.x. >> > > > > >> > > > > The Oak team are unwilling merge the patch to 1.6 and have >> > > > > asked that >> > > > > Sling >> > > > > depend on the latest release of Oak 1.7. >> > > > > >> > > > > How does the Sling team feel about this ? >> > > > > >> > > > > The patch for SLING-7140 cant be merged until the API is >> > > > > available in Oak >> > > > > in some form and I don't want to depend on Oak 1.8-SNAPSHOT as >> > > > > this will >> > > > > block Sling releases of the bundles involved. >> > > > > Best Regards >> > > > > Ian >> > > > >> > > > >> > > >> > > >> > > >> >> >
