Hi, On 13 October 2017 at 15:46, Julian Sedding <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 ([email protected]) 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 <[email protected]> wrote: > >> > >> > > >> > > >> > On 11 October 2017 at 11:25, Robert Munteanu <[email protected]> > >> 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 <[email protected]> > >> >> > 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" <[email protected]> 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" <[email protected] on behalf > >> of > >> >> > > > [email protected]> 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 > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > > >> >> > > > >> >> > >> >> > >> > > >> > >> >
