Hi,
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
architecture.
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.
BR,
Jukka Zitting
