I appreciate that you are pushing hard to have a defined release *NOW* and do NOT want to wait for the DSN mailet. I do not want to lose the fixes in the common code that are already in place since 2.2.0a18, and I really have no idea how much coverage we've had on 2.2.0a-anything, much less 2.2.0a18 in specific. FWIW, one of the reasons I've not pushed for a 2.2 release before was that I wasn't comfortable with the level of testing.
Nothing against any changes, DSN mailet or MLM improvements or the 5 issues you had flagged earlier today as "to fix" for 2.2.0. I just think we'd be best served (community, users, developers, legally) by abandoning our current alpha-only release pattern.
By the way, I did think that we had agreed on a release plan in Feb, and we've fixed all of the major defects that could reasonably be addressed without risk to the overall code quality. Still unincorporated from that plan are:
Vincenzo's S/MIME matchers & mailets Bayesian matchers & mailets DSNBounce mailet SpamAssassin Mailet Maildir
which are new features. Those aren't in JIRA, but I'll start work on a James v3 RoadMap after we get v2 put to bed.
They're nice goals... I find feature plans somewhat antithetical to open source since it's basically a scratch-the-itch development process.
As a compromise, I'm proposing to post 2.2.0RC1 *today*. Not next week, the week after, or the week after. Post it today with the intent of releasing 2.2.0 next Friday if there are no blocking issues. Give everyone one week to know that this is intended to be the 2.2.0 Release. This gives everyone a chance to synchronize and test THIS build.
Ok, tag, branch, and post 2.2.0rc1 today 4/16, with an aim to start a vote and release next Friday 4/23 (so get on mirrors by Monday 4/26). You want to do this, or should I? I can get to it late tonight.
When the DSN code is ready, we can test and release it as a separate jar as an example of a custom mailet with additional dependencies, and then include it in 2.2.1 (if there is one). There is something attractive about demonstrating the custom mailet technology that way.
Bah, I think that's pointless. Let's release often, and DSN will happily get picked up in 2.2.1 soon enough.
If we want to talk about a mailet pack or something like that for a separate release, let's discuss that as an issue separate from the James server release process.
The next thing after this release is to finish the merger, based now on this released code. As soon as we have that, I would suggest adding the remaining items for which we have code, e.g., DSN, jSieve, maildir, SpamAssassin, etc., along with the Mailet API changes and SMTPACL, and release the merger as a James v3 base. From my perspective, the first thing I want to be doing after the pure merger is integrating the streaming code, which will be key to the memory footprint reduction. After that come JNDI and other enhancements.
Be warned, I'm going to start pushing for a 3.0 release as soon as you get things merged and committed. I want to get us back into the mode of releasing frequently, so will be applying pressure to bring workable resolution wherever possible.
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
