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 Re: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Date Wed, 05 Mar 2008 20:55:25 GMT
On Wed, Mar 5, 2008 at 10:37 AM, Stefano Bagnara <apache@bago.org> wrote:
> Noel J. Bergman ha scritto:
>
> > Robert Burrell Donkin wrote:
>  >> trunk was forked from 2.3.0 several years ago now
>  >
>  > Yes, I am keenly aware of the last time I had time to work on a release and
>  > the communal disinterest or inability to do one since.  One question I have
>  > is, should the next release come from a v2.3.0 follow-on, or should we even
>  > attempt to extricate something from trunk.  And if the latter, then we are
>  > going to have to compare that against the known, good, codebase.  And, yes,
>  > as the person who did this the last time, I'm well aware of the effort
>  > involved.  Hence my question and concerns.
>
>  Are you referring to the merge between trunk and 2.2.0 code between 2004
>  and 2005 ? I think it is a different story. That branch involved much
>  less code than current v2.3-trunk differences but included major changes
>  to mailet api.
>
>  I don't agree that the only way to produce quality is to compare with
>  previous work. The fact that you don't know what is in trunk because you
>  had no time to review most commits doesn't mean that this is the same
>  for everyone else here.

+1

releasing a 3.0 would involve a series of milestone releases to build
confidence in the new codebase rather than a manual process of
re-evaluating every change. i hope to have a function complete
IMAP4rev2 working in time for ApacheConEU. we could aim to create an
initial 3.0 technology preview then.

IMHO the major remaining task to be tackled for 3.0 is to revise the
application assembly. i'm happy with avalon but i accept that using
avalon (as an IoC) is a major negative factor in attracting new
developers for a variety of reasons. i think JAMES needs a new
micro-kernel architecture.

>  IMO there is no need at all to merge v2.3 and trunk this time. This time
>  we had no single fix in v2.3 that has not been done in trunk too. We
>  have been very diligent and we avoided diverging branches so to not
>  repeat the post-2.2.0 mistakes.
>
>  If you need time to check code quality in trunk, well, take your time
>  and let's discuss about specific code.
>  If you think it doesn't worth your time then start working on v2.3 and
>  make a proposal from there.

+1

>  >> contains significant differences not only in organisation but also design.
>  >> i doubt whether anyone has the time required to perform a comprehensive
>  >> manual comparison now whether the mailets are in trunk or elsewhere.
>  >
>  > Well, that's part of the issue.  Due to the reorg, we will be hard pressed
>  > to compare the changes in the current code from the released code.
>
>  If you exclude IMAP most code has changed BEFORE the code
>  reorganization. So it should be easier than you think. You will see that
>  since dicember 2006 we had very limited changes in the sources (if you
>  exclude IMAP and its dependencies).
>  It is a lot of code, because we implemented a lot of features and fixed
>  a lot of long standing issues in our services API.

excluding IMAP+deployment, the only change that springs to mind are
the JAMES handler framework improvements. if inheritance were to be
replaced by delegation for this framework then most modules would have
very few changes.

- 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