james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Burrell Donkin" <robertburrelldon...@gmail.com>
Subject What's In 3.0? [WAS Re: [VOTE] next-major from trunk will be 3.0]
Date Mon, 06 Aug 2007 21:27:26 GMT
On 8/3/07, Stefano Bagnara <apache@bago.org> wrote:
> Danny Angus ha scritto:
> > On 8/3/07, Stefano Bagnara <apache@bago.org> wrote:
> >
> >> I also agree that it added confusion: I had a clear view on what
> >> next-minor and next-major was and at that time I thought it was clear to
> >> everyone (I'm used to labels to identify software sprints). But the
> >> facts proved my believing was wrong.
> >
> > I think that was the problem, not that it was a bad idea, but that we
> > didn't all have the same understanding. We use labels in this way at
> > work too, to great effect, somehow it just didn't catch on here.
>
> FWIW, even now that we have 3.0 instead of next-major, I don't have an
> understanding of people preferences/ideas about the future of JAMES. Not
> that my understanding is important now, but I hope someone will better
> collect such moods/opinions.

+1

> It "seems" we now agree we need a 3.0M1, this would be already a great
> step: I really hope to see a 3.0M1 out there, soon!
>
> 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.

feedback from users should be very useful in deciding the best approach

the handlerapi isn't really my area so someone else would need to
volunteer push this forward

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message