Hi there,

context: <https://issues.apache.org/jira/browse/JCR-4429>

So we have an API change in jackrabbit-api, which is used inside Oak. To
get it in there, we released Jackrabbit 2.19.3 (unstable) and use that
in Oak trunk for now.

For Oak, a new stable release (1.14.0) is planned for early June. By
that time, we need to get rid of the dependency on an unstable
Jackrabbit release.

Note that Oak has changed to a release model with multiple major
releases per year (with changed guarantees on how long they'll be
maintained). We haven't made the same change in Jackrabbit yet, though.

Given the time pressure, my proposal is to simply *backport* JCR-4429 to
Jackrabbit 2.18.x. It's just a set of new interfaces, after all, not
actually implemented by Jackrabbit. We'll then release 2.18.2, update
Oak trunk to use that, and are done.

Going forward, we should however try to break this dependency. After
all, it's Oak which is driving the evolution of jackrabbit-api, so it
really should move over there. This will eliminate the top reason why we
have been branching Jackrabbit in the past.

To do that, the following should work:

- (svn) cp the subproject over to Oak, align the POM, but do not touch
package name or export versions
- once a new stable Oak is released (1.16, sometime later this year),
drop the jackrabbit-api subproject, and inside the other Jackrabbit
subprojects reference the new Oak artifact
- we probably should try to generate a "tombstone" release of
jackrabbit-api, that would point people to the changed location (needs
research...) before entirely removing the subproject

Feedback appreciated,

Julian

Reply via email to