robert burrell donkin ha scritto: > On 7/17/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> IMHO it is not spring support to justify a milestone or not. It is a >> cool, long awaited feature, for sure (and kudos to Bernd for this) but >> Spring support will be only one more of the *127* bugs fixes/features we >> already have in trunk: >> https://issues.apache.org/jira/browse/JAMES?report=com.atlassian.jira.plugin.system.project:roadmap-panel > > often having a bit of cool new functionality to aim at helps to > concentrate the mind and it's easier to get excited about one cool > feature than hundreds of minor fixes and changes...
Sure, FYI here is a list of new features already in trunk: - SMTP Server - 8bitmime support - Greylisting support - SPF support - Better SpamAssassin support - Support for POP-before-SMTP (roaming users) - URI blacklist support - URIRBLHandler for fastfail - Add reverse lookup checks and HELO/EHLO checks in SMTP - Support Connection Limit per IP - Virtual hosting / Dynamic reloading / JMX+RemoteManager management - introduced the VirtualUserTable (VUT) Service - Support dynamic reload of servernames - Added JMX+RM operations for spool/mail repositories and user management. - Support the use of VUT to extract servernames. - Added management for the new VUT store/repository. - Added management interfaces and remotemanager commands to manage the servername list - Critical Issues - Almost fully rewritten DNSServer to fix OOM issues and some critical caching bug. - Added search-domain configurability to DNSServer - Introduced Commons Daemon to run james as non root. - Furthermore we have now 2 experimental "IMAP servers". IMHO some of them is at least as cool as spring support. Of course this is only a personal opinion: I wrote the list only to update you on what's in trunk, as you wasn't here when we worked there. I have to admit that I had forgotten most of them in this months, too. My personal pick is the much better support for virtual hosting that come out from some of the VUT-related features (mainly because fastfail and imap are not yet mature enough). >> My question was about the plan details: I was curious about how do you >> propose to manage the milestone cut. > > dunno :-) same here :-) ... or better :-/ > i'm not proposing anything ATM just posing the question: would a > milestone from trunk containing spring integration be a good idea? > >> While I'm here, I've a doubt: is there any limitation in packaging an >> early access version of javamail in a official release (even if it is >> only a milestone ?). > > this is a question of policy > > in terms of apache policy, it's really a question of licensing. before > thinking about a release, all the licenses need to be checked anyway > so it's no real extra work. > > in terms of JAMES policy, that depends on what we collectively decide > is appropriate for a milestone release Ok. Then I'm fine with the use of SNAPSHOT/ea/beta dependencies in milestones/alpha/beta releases (as long as their license allow this). >> I remember in past the SUN "ea" releases had a >> special license (that wouldn't have allowed a release), but now in the >> jar LICENSE file I can't find any pointer but a standard CDDL. > > AIUI sun have significantly rationalised their licensing policy recently > > - robert Right. I was referencing it to make a concrete example of a license (the old early access license) that would have not allowed us to make an ASLv2 release distributing that code. Thank you, Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
