[PROPOSAL] Experimental Modules (Or - the code that came in from the code)

i would like to suggest that JAMES adopts a slightly different approach to the development of extra and alternative functions. ATM we use branches for experimentation but i think that these are several disadvantages in this: * collaboration is more difficult * hard to shared between branches * mo

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

On 5/9/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: so, i would like to propose we allow experimental modules in trunk. We could even have an "experimental" or "technology preview" distribution. I like this idea a lot, a whole big lot. I don't think we should prefix the names, but per

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

On 5/9/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: i would like to suggest that JAMES adopts a slightly different approach to the development of extra and alternative functions. ATM we use branches for experimentation but i think that these are several disadvantages in this: * collabor

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

On 5/10/07, Danny Angus <[EMAIL PROTECTED]> wrote: On 5/9/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: > so, i would like to propose we allow experimental modules in trunk. We could even have an "experimental" or "technology preview" distribution. I like this idea a lot, a whole big lot

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

+1 about allowing experimental modules in trunk, BUT I think that we should evaluate each specific case and not abuse of it. I want to avoid dead code in trunk (we have had many branches/sandbox that was simply experiments and not born to be included in trunk). Many times I think that branches wi

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

+1 I fully agree with Bernd ideas. Stefano Bernd Fondermann ha scritto: > Sounds like a billiant idea. Will it work, though? > Won't this over time lead to a trunk swamped with half-baked years-old > experiments? > What if the experiment is to change how modules are working together? > (Current m

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

I would prefer to have a single distribution including stable and experimental modules. Experimental modules are disabled by default. I think we should not complicate our workflow with multiple different distributions: we are already too slow even with a single distribution, we should first become

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

On 5/10/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: I would prefer to have a single distribution including stable and experimental modules. Experimental modules are disabled by default. +1 telling our user about feature maturity is something we already do at http://james.apache.org/server/i

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

Bernd Fondermann ha scritto: > > If we'd maintain ultra-stable and cutting edge releases side-by-side > (just by exchanging modules) we could maybe even _accelerate_ the > project. > Unfortunately it is a dream and a dream will remain: this would only be possible if the interface between modules

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

On 5/10/07, Bernd Fondermann <[EMAIL PROTECTED]> wrote: On 5/9/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: > i would like to suggest that JAMES adopts a slightly different > approach to the development of extra and alternative functions. ATM we > use branches for experimentation but i th

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

On 5/10/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: As an example in the past days I've heard people saying they want to make JCR *THE* api between modules: this is a change that IMHO cannot live together with the old style in the same build tree. provided that care is taken over packagin

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

robert burrell donkin ha scritto: > provided the code is factored correctly and the build is modular, it can > > the abstract socket/protocol handlers should be factored into > libraries. functions should depend on whatever libraries they require. > when factored in this fashion, new and old imple

Re: [PROPOSAL] Experimental Modules (Or - the code that came in from the code)

On 5/10/07, robert burrell donkin <[EMAIL PROTECTED]> wrote: > What if the experiment is to change how modules are working together? > (Current modules have very tight coupling.) This would have to be done > on a branch nevertheless, if we wouldn't want to break what's in > TRUNK. IMHO loosening