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
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
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
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
+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
+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
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
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
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
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
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
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
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
13 matches
Mail list logo