Hi all, sorry im quite busy at the moment with some migrations.. So I will try to respond to all mails later.. Some comments are inline..
Am Dienstag, den 22.01.2008, 19:39 +0100 schrieb Stefano Bagnara: > 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. +1 > > >>> 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. > > Noel made some reference to very limited features to be "backported": > per IP connection limit, the old dns cache issue. > I would like to understand what else and how would be included in a > similar backport. As an example, the way Noel proposed to fix the dns > issue in next-minor is not a backport from trunk, because the dnsserver > in trunk has a lot of fixes more and we changed a lot that service and > the way other components interact with it (moving from static uses of > the component to service injections). > > >>> 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? +1 > > >>> 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? > > > 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?] -> beta > - SPF support [beta] > - Better SpamAssassin support [beta] > - Support for POP-before-SMTP (roaming users) [norman?] -> beta > - URI blacklist support [norman?] -> alpha > - URIRBLHandler for fastfail [norman?] -> alpha > - Add reverse lookup checks and HELO/EHLO checks in SMTP [norman?] -> beta > - Support Connection Limit per IP [beta] > > - 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] > > - 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? > > Stefano > > bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
