Hi, I think it would be better to go back and look at the earlier proposals for this patch that did not require any new APIs from Oak to work. They were written that way to avoid exactly the problem of a long dependency chain now blocking the feature.
Since Oak only releases its first stable release towards the end of an AEM GA cycle and Sling can't release anything depending on that until Oak is table, that leaves the short period between Oak going Stable and feature freeze for the next version of AEM for everything else to be done. If feature freeze is missed, then next opportunity comes a year to 18 months later, which isn't very agile and certainly not what Sling is about. Sling is an Apache project and should not really be governed by the AEM release cycle, but given there are so many Adobe employees and partners working on Sling and AEM is possibly Slings larges stakeholder that is almost impossible to avoid. So we have to find a way of living with this, which is why the first patch for the feature didn't require any APIs in Oak. Best Regards Ian On 16 October 2017 at 12:34, Julian Sedding <jsedd...@gmail.com> wrote: > Yes, branching could be an option. To avoid confusion, it may be > prudent to do any releases from such branches only with odd bundle > micro-versions and a qualifier. Such a version number could e.g. look > like this: 1.4.7-EXPERIMENTAL. > > That way a released artifact is clearly labelled as being experimental > (or whatever qualifier is chosen) and the odd micro-version number is > one that's usually reserved for snapshots (by convention in Sling). > This may cause people experimenting with such bundles some minor > hickups (e.g. snapshot overriding experimental release bundle), but > that should be acceptable IMHO. > > Regards > Julian > > > > On Fri, Oct 13, 2017 at 6:37 PM, Ian Boston <i...@tfd.co.uk> wrote: > > 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 > >> >> >> >> > > > > >> >> >> >> > > > > >> >> >> >> > > > >> >> >> >> > > > >> >> >> >> > > > >> >> >> >> > >> >> >> >> > >> >> >> > > >> >> >> > >> >> >> > >> >> > >> >
