Hi, The bundles are Sling API Sling ResourceResolver Sling JCR Resource Sling GET Servlets.
given these will probably get fixed between now and when Oak 2.0 is released and could end up in a product I don't think an internal release is a viable low risk option. I think the only viable option is to wait for Oak 2.0 to be released, given the Oak backport policy of no new features or API changes in stable branches. Best Regards Ian On 13 October 2017 at 17:25, Chetan Mehrotra <chetan.mehro...@gmail.com> wrote: > Another possible option can be to branch such bundles which depend on > Oak API and do unstable releases for them i.e. only odd version > release. This would allow implementing parts in Sling which rely on > new features implement in Oak trunk Chetan Mehrotra > > > On Fri, Oct 13, 2017 at 8:25 PM, Ian Boston <i...@tfd.co.uk> wrote: > > Hi, > > > > On 13 October 2017 at 15:46, Julian Sedding <jsedd...@gmail.com> wrote: > > > >> AFAIK Oak does not use semantic versioning for packages within uneven > >> minor version changes (i.e. 1.8 will be baselined against 1.6). This > >> gives the Oak dev team freedom to experiment with API changes within > >> the uneven "development" version (i.e. currently 1.7). > >> > >> Sling, on the other hand uses semantic versioning and (implicitly?) > >> requires that any bundle can be released at any point. This > >> requirement conflicts with Oak's "unstable" development releases in so > >> far as Sling should not create any releases that reference Oak's > >> intermittent (non semantic) package versions. Doing so could lead to > >> update problems or badly wired OSGi bundles down the line. > >> > >> IMHO the "unstable" label of Oak's uneven minor versions refers not to > >> unstable or poorly tested code, but acknowledges that semantic > >> versioning is only enforced in releases with even minor version > >> numbers. > >> > >> This implies that using "unstable" Oak for testing within Sling should > >> be fine. Releasing bundles with "unstable" Oak dependencies is > >> definitely slippery slope, even though it does not have to lead to > >> problems. > >> > > > > Underlined by the appearance of some new bundles in 1.7.9 that were not > > there in 1.7.8, however AFAIK the package versions were not changed. > > > > Since I was wrong to assert 1.7.8 was close to 1.8.0 (see other thread), > I > > have asked oak-dev to clarify it it is or not. If its not, I also dont > want > > to slip down that slope. > > Best Regards > > Ian > > > > > > > >> > >> Remains the tricky question: how do we build on cutting edge Oak > >> features? Branches could be one option (especially once we're on Git), > >> with no (official) releases from the branch. > >> > >> Regards > >> Julian > >> > >> > >> On Fri, Oct 13, 2017 at 11:56 AM, Ian Boston <i...@tfd.co.uk> wrote: > >> > Hi, > >> > My View is that it would be dangerous to depend on 1.11.1 but safe to > >> > depend on 1.11.25 if 1.11.25 was known to be near to the branch to > >> 1.12.x. > >> > The closer to 1.11.1, the greater the risk of instability, the closer > to > >> > 1.12.x the less the risk. > >> > > >> > IIUC Oak have started to discuss the possibility of branching 1.8.x, > >> which > >> > makes 1.7.9 relatively close to that branch. That said, I made an API > >> > change that appeared in 1.7.9 ;). It all depends on the detail in > every > >> > case. There are no rules that always work. > >> > > >> > Best Regards > >> > Ian > >> > > >> > > >> > > >> > On 12 October 2017 at 16:28, Matt Ryan <o...@mvryan.org> wrote: > >> > > >> >> 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 > >> >> >> > > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > > >> >> >> > > > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> >
