jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jzitt...@adobe.com>
Subject Re: [jr3] Rethinking our Jackrabbit 3.0 roadmap
Date Thu, 02 Dec 2010 09:55:07 GMT

On 02/12/10 09:56, Thomas Mueller wrote:
> There are multiple ways to reach our goals:
> a) refactor in very small steps
> b) replace piece by piece
> c) replace all code we have in one huge step
> As far as I understand, you are afraid that c) would take too long?

Yes. Not necessarily too long in the sense that we shouldn't do it, just 
too long to stop making incremental and sometimes backward-incompatible 
progress in the stable branch.

> I would probably try to do b).

I'd like that, but as you say there may be issues with that. Going this 
route it would be even more important to allow major version upgrades 
like 3.0 and 4.0 before we're fully done implementing the next-gen 

> If we anyway want to replace "Core" later on (what you call Jackrabbit
> NG?), some of your refactorings on the current trunk would be "lost" later
> on. Basically we would do the work twice: first refactor the current core,
> and later on replace the current core. In my view, some changes are not
> worth doing twice (more flexible repository configuration, storing search
> indexes inside the repository), but maybe I'm wrong.

The value of such changes is not just in having those features earlier 
in a stable release, but also in making the upgrade path smoother as we 
can split one huge migration to many smaller ones that are then probably 
also easier to automate.

Also, having new features or optimizations go out early in the stable 
releases gives us a lot of good feedback and experience on how they work 
in practice. And there are a lot of users who'd rather have a partial 
optimization or improvement next year, than a fully rearchitected system 
three to five years down the line.


Jukka Zitting

View raw message