On Jan 22, 2008 6:39 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: > Robert Burrell Donkin ha scritto: > > it's a milestone rather than an alpha. we don't have alpha quality > > code that we intend to fix up and release but a mixed bag which we > > cannot promise will be compatible with an eventual 3.0 release > > I agree. And if we don't plan to include IMAP then probably "2.5" would > be a better name, for what will not be compatible with 3.0, but can lead > to an intermediate release.
(it's not just IMAP but also the backend that IMAP depends on that isn't ready) > >>> next-minor (2.4 ?): this is Noel field. My opinion is unchanged. IMHO we > >>> should work on trunk because backporting to the old structure IMHO is > >>> too much work and does not make sense. BTW if anyone is willing to work > >>> on this, well, why not: the more we release the better. > > > > depends on the feature: i was wondering about backporting components > > rather than source. i suspect that this should be much easier. > > I'm not sure I understand the "backporting components". > > v2.3 branch is not "modularized" like trunk and there are many changes > at the api level between v2.3 and trunk, because we tried to fix up some > service interface to better modularize the components. (moving code around into modules really isn't a substantive issue and is easy to reverse) (whether it's called 2.5 or 3.0) the APIs are the main issue - we really need to take a good look at the way that JAMES is composed > >>> I think a better plan is to try to release at least one milestone from > >>> trunk and depending on the feedback we'll have on the milestones we'll > >>> be able to decide whether it's better to make more milestones from trunk > >>> or it is better to branch for consolidation. > >>> > >>> I don't speak about IMAP (I think Robert will tell us what he thinks > >>> about IMAP modules and their status) > > > > IMAP is better but isn't ready > > What about a release including IMAP only as an experimental/alpha > module, but having the remaining server as a 2.3 backward compatible > server with some improvements? the current backend APIs touched by IMAP are not satisfactory: releasing them will just create yet another fork without IMAP. we'll end up in exactly the same situation until someone steps up to sort out the APIs, milestones are the best approach > >>> but I think most of the other > >>> modules in trunk are ready (since 13 months) for a milestone/alpha/beta > >>> release and they already provide a lot of new features compared to > >>> 2.3.1. Most of the code in trunk should be storage and config.xml > >>> compatible with 2.3.1. > > > > i'm not sure how true is (there are a number of features touched by > > IMAP which aren't ready) > > What features? The mailboxmanager is only used by IMAP. I don't think > there is much core code that has been changed to accomodate IMAP > modules. Had I forgotten anything? mailbox manager and implementations are the major areas. this couples over to some some other functions such as jsieve integration. it's the APIs that are important: IMO the API dependencies really need to be understood and sorted out > > i think that it would be useful to compose a list. > > > > which new features: > > > > * ready for full release? > > * beta? > > * alpha? > > Most code have to be tested more (and that's why we need a release), but > I think most of it can be considered beta as we already know some user > is running trunk code. > > From an old email dated 17/07/2007 (Spring Deployment) here is a list > of features in trunk: > Sure, FYI here is a list of new features already in trunk. I added the > alpha/beta status or the name of who may tell us what's the status: > > - SMTP Server > - 8bitmime support [beta] > - Greylisting support [alpha/norman?] > - SPF support [beta] > - Better SpamAssassin support [beta] > - Support for POP-before-SMTP (roaming users) [norman?] > - URI blacklist support [norman?] > - URIRBLHandler for fastfail [norman?] > - Add reverse lookup checks and HELO/EHLO checks in SMTP [norman?] > - Support Connection Limit per IP [beta] which of these improvements are in the protocol and which are mailets? > - Virtual hosting / Dynamic reloading / JMX+RemoteManager management > - introduced the VirtualUserTable (VUT) Service [beta] > - Support dynamic reload of servernames [beta] > - Added JMX+RM operations for spool/mail repositories and user > management. [bernd?] > - Support the use of VUT to extract servernames. [beta] > - Added management for the new VUT store/repository. [alpha/beta] > - Added management interfaces and remotemanager commands to manage the > servername list [alpha/beta] how is virtual hosting coupled to the protocols? > - Critical Issues > - Almost fully rewritten DNSServer to fix OOM issues and some critical > caching bug. [beta] > - Added search-domain configurability to DNSServer [beta] > - Introduced Commons Daemon to run james as non root. [beta] > > >>> Unfortunately now I cannot be active as I was 13 months ago when I > >>> proposed to cut a milestone from that code, but this is anyway my > >>> opinion on the code we have. > >>> > >>> Most of our "SNAPSHOT" dependencies have been upgraded to finals in the > >>> past year, now we only have mailet, jsieve and mime4j as snapshot > >>> dependencies. Maybe we should try to cut releases for that products > >>> before trying with Server (but this is not mandatory). > > > > yes, this is the first step > > Well, this seems a plan. What is blocking mailet/jsieve/mime4j releases? mailet, jsieve - energy mime4j - completion of refactoring - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
