You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Norman Maurer <no...@apache.org> on 2007/08/07 19:54:50 UTC
Re: What's In 3.0? [WAS Re: [VOTE] next-major from trunk will be
3.0]
Stefano Bagnara schrieb:
> Robert Burrell Donkin ha scritto:
>
>> On 8/3/07, Stefano Bagnara <ap...@bago.org> wrote:
>>
>>> My opinion is unchanged since next-major: imho we can have a release
>>> even tomorrow, maybe we should consider whether it is better to release
>>> another version of the handlerapi (the current trunk) or it is better to
>>> release 3.0M1 using the 2.3.1 handlerapi, or it is better to release one
>>> of the experimental handlerapi.
>>>
>>> I'm not a fan of the current handlerapi as I think it introduce
>>> incompatibilities with the experimental 2.3.x support and it does not
>>> provide a sufficient platform for the future (so I expect to see further
>>> changes there sooner or later), but for the major goal of a release I'd
>>> sacrifice almost anything, so I'm fine with any code will be there.
>>>
>> the milestone is technology preview. if there's some dispute about the
>> best implementations of parts of the code then let's port them in as
>> modules into trunk (we can argue about whether their labels later).
>> then all we need to decide is which should ship as default.
>>
>
> I agree.
>
>
>> feedback from users should be very useful in deciding the best approach
>>
>
> Will we be able to support our users on every implementation we have in
> trunk? I personally have limited knowledge in some handlerapi code and
> with the imap modules.
> IMHO we should at least care to release as default something that we are
> ready to support and for which someone will reply to user questions.
>
>
>> the handlerapi isn't really my area so someone else would need to
>> volunteer push this forward
>>
>
>
> I have knowledge of the experimental handlerapi code we release in
> 2.3.x. The we had 2 branches, one sandbox and trunk evolving with
> different solutions.
>
> I know what's in the handlerapi-experiment sandbox and I can tell it is
> a big refactoring involving changes in the core and in most modules so
> to refactoring of the current code to support a SEDA pattern, so maybe
> we should ignore it for 3.0M1.
>
> I don't know much of the trunk vs 2.3 and the 2 branches: maybe Noel or
> Norman can help us identifying what's what and what do they think we
> should include in M1.
>
I whould stick with the version from 2.3.x. The new design in trunk is
to "incomplete". But i think the best code is still in the handlerapi
project Stefano and me put in the sandbox.
> What I would like to avoid is releasing one more different experimental
> handlerapi with the knowledge we will change it again in M2 and then
> again in M3 and so on. In this case I would prefer to revamp 2.3 code
> for handlerapi and keep that module as "default" for a while (while we
> better understand what can be done there).
>
> Stefano
>
+1
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org