Re: [jr3] Rethinking our Jackrabbit 3.0 roadmap

[Thomas Mueller <mu...@adobe.com>]

Hi,

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? A bit
simplified, for a) you always have a stable version, but it takes a very
long time until you are fully done. Plus, you tend to have a large number
of 'temporary hacks', and all developers need to fully understand the
current code. With c) you have the longest delay until you get new
features, but the smallest amount of total work. Plus there is a bigger
risk management cancels the project before it's done (but I guess the risk
is lower for open source).

I would probably try to do b). The problem is: what are the pieces? Maybe
"Core", "RMI", "DavEx". Maybe "Search" is part of "Core", maybe not (not
sure). Maybe "Versioning" and "Security" could easily be re-used from the
current core.

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.

Regards,
Thomas

Re: [jr3] Rethinking our Jackrabbit 3.0 roadmap

[Ard Schrijvers <a....@onehippo.com>]

On Thu, Dec 2, 2010 at 10:55 AM, Jukka Zitting <jz...@adobe.com> wrote:
>
> 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.

I'd also opt for (b) as this seems to me to have the best chance of
success and acceptance

Regards Ard

>
>> 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.
>

Re: [jr3] Rethinking our Jackrabbit 3.0 roadmap

[Jukka Zitting <jz...@adobe.com>]

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