sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Boston <...@tfd.co.uk>
Subject Re: Depending on Oak 1.7.x
Date Fri, 13 Oct 2017 14:55:20 GMT
Hi,

On 13 October 2017 at 15:46, Julian Sedding <jsedding@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 <ieb@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 <oss@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 (ieb@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 <ieb@tfd.co.uk> wrote:
> >>
> >> >
> >> >
> >> > On 11 October 2017 at 11:25, Robert Munteanu <rombert@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 <stefanegli@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" <stefanegli@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" <ianboston@gmail.com
on behalf
> >> of
> >> >> > > > ieb@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
> >> >> > > >
> >> >> > > >
> >> >> > >
> >> >> > >
> >> >> > >
> >> >>
> >> >>
> >> >
> >>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message