james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Merging plan (was Build process in maven?)
Date Wed, 29 Oct 2003 18:59:31 GMT
Noel J. Bergman wrote:
>>So to just get to a merged 3.0 release, we could do the following
> Are you proposing that what is currently v2.2.0 test builds be released as
> v3?

Err, no... I mean merge from a codebase perspective, not overwrite. 
Feature-wise, I don't believe there is much in 3.0 that isn't in 2.2.

>>1. Move to latest release packages from Avalon.
> I think that we already have them in the MAIN branch.  If not, we should.
> Steve is running James with them under Merlin, although we still still want
> to release with Phoenix for at least another set of releases, even if we
> support Merlin as well.

Yeah, I'm not much use resolving this one.  I recently joined the Avalon 
mailing lists but am still unclear the release state (the new web looks 
great though!)

>>2. Discuss and resolve the mailet API changes.
>>I think we have some consensus about 2... we originally were planning
>>more sweeping changes and include repository changes, but I don't know
>>if that is appropriate since we're still stuck on the IMAP changes.
> I would like to defer the Mailet API changes in the MAIN branch,
> particularly the ones exposing repositories.  After we the next Release, we
> can look at changes, including <mailet> configuration.

I had that in mind, and with both Danny and you saying that, I'm happy 
with it.  Anyone else?

>>3. Address any discrepancies (code changes only applied to one or other,
>>   or otherwise require resolution).
> Since I was making them in parallel for quite some time, I believe that at
> this tome, such discrepancies are limited (a) improvements in v2 not yet in
> MAIN, (b) changes in MAIN that reflect Avalon changes.  If anyone knows of
> anything else, please speak up.
> And, yes, it is just grunt work.  What I would do (if I were doing it) would
> be to run a visual diff for each file from v2 and MAIN, find those
> differences, copy over into v2 the ones that we need, tag MAIN, and then
> merge the v2 code into MAIN.  We'd end up using the MAIN build process,
> which should actually be the nicer one (after all the work Stephen and Leo
> did), with the v2 code updated for current Avalon.

I think that will be messy since there has been so much changes on each, 
but I don't have a better suggestion.  grunt grunt grunt.

This really could expose our Archiles heel though, which is a lack of 
adequate testing to make sure the merged version works well.  Have we 
made any progress/thoughts on how to automate testing?

Serge Knystautas
Lokitech >> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com

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

View raw message