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.
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?
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?]
- 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]
- 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
