Hi, On Tue, Oct 23, 2012 at 5:03 PM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Here's an early draft of how this could work out in terms of the > Jackrabbit roadmap:
Seems like we have fairly good consensus on the big picture, so let's start laying some more concrete plans! > * Jackrabbit 2.6: We target at releasing a stable Jackrabbit 2.6.0 > version sometime around the end of this year. As usual, we'll have a > 2.6 maintenance branch for upcoming 2.6.x patch releases. We missed the end of the year already, but let's try to get this out pretty soon. I'll follow up with in a separate thread. > * Jackrabbit 2.x: Just after branching 2.6, we'd create a separate 2.x > development branch for future work based on the current Jackrabbit > architecture. This branch would give us a chance to more than just bug > fixes on the 2.x codebase for at least a few more years until everyone > is comfortable upgrading to an Oak-based repository. In fact, after thinking about this a bit more, I'd rather keep the 2.x codebase in trunk parallel to the new Oak components we'll be moving in after 2.6 is branched. This should make it easier to share the code in jcr-commons and other generic components. Having the 2.x and Oak codebases parallel in the same trunk will also make it much easier to implement and test good migration tools. > * Jackrabbit 3.0: Early next year, after the 2.6 and 2.x branches have > been created, we'd replace the current trunk with an Oak-based JCR > implementation. As mentioned above, instead of replacing the trunk entirely, I'd keep both codebases in trunk for now and include *both* the 2.x and Oak repositories in things like jackrabbit-webapp and jackrabbit-standalone, with a configuration option to decide which repository implementation should be used in each particular deployment. Having both codebases included in the same deployment packages will make it easier for downstream users to upgrade to Oak with minimum changes to their deployments. Also things like the backup and migration tools in jackrabbit-standalone should be easy to use also with Oak. With this hybrid approach I'd go first for a stable 2.8 release sometime before summer, with the traditional 2.x repository still the default deployment option but with Oak included as an alternative. Then in unstable 2.9 we can deprecate the 2.x repository and make Oak the default. Finally around the end of the year (or whenever we're ready for it) we can cut Jackrabbit 3.0 as the stable Oak-based repository. That release (and all 3.x versions) should still contain also the older 2.x codebase for full backwards compatibility (except for features deprecated already in 1.x, those we can drop in 3.0). BR, Jukka Zitting
