james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: 2.3.x vs trunk [WAS Re: [VOTE] Mailets -> Mailet subproject]
Date Wed, 05 Mar 2008 00:32:19 GMT
Robert Burrell Donkin wrote:

> Noel J. Bergman wrote:
> > It sounds OK, so +1 in general, but with all of the refactoring, we've
> > making it increasingly difficult to compare versions of JAMES.  This
> > not be so bad if we had ever made a stable baseline prior to the
> > refactorings, but instead we started with unstable baselines and
> > meaning that we will have to do considerable manual comparison between
> > only known stable JAMES code (2.3.0) with its known defects and the
> > trunk(s) for JAMES and Mailets.

> 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.

> 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.

> i think that moving the mailets into a separate project should make
> things move managable.

In the long run, I agree.  Even in the mid-term, we can compare the Mailets
in the new project with those in the release, and validate the changes.

> a single consolidated library can used for both 2.x and 3.x releases (as
well as trunk).

We'll may have to make some changes to allow that, since people didn't treat
the code in a manner that would ensure this simple statement.  This would be
another benefit from your proposal.  Separating the Mailet library from the
server would discourage people from changing them in lockstep.

That said, we want to be able to evolve the Mailet API, in a controlled and
proper manner.

	--- Noel

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

View raw message