Robert Burrell Donkin ha scritto: > i've been having a little think recently, in particular about user > postings on the list. i think i can see a realistic path if there's a > consensus that this is the way we want to take james forward... > > Observations: > * Felix Karaf (OSGi container) is very cool. this opens up lots of > cool possibilities for mixing protocols and is very interesting to me.
Interesting. I'd like to see a POC about it, before embracing such a technology. > * IMAP may well be ready for a 0.1 release in the near future :-) but > will focus on spring and OSGi tooling with only limited support for > avalon +1 > * Stefano and Norman are very busy these days. so just directly > releasing 3.0 is looking harder and harder... Trunk was almost ready for a alpha/beta release 2 years ago, so I don't see this so hard. This require the same effort as any release of james-server: until no one will need a release and will take the time to build some test release we won't see a release. > * The recent threads from users are telling us that we really need to > have a 2.x roadmap for mail server users (as opposed to mail > application developers) they don't care about 2.x or 3.x. IMO they simply would like to have new features that are in svn since years. > Proposal: > * Use 2.x for mature, stable releases aimed at mail server users > retaining pheonix as the container > * Target 3.x at mail application developers focussing on OSGi and Spring > * Move code from 3.x to 2.x by factoring out libraries with multiple > modules to allow optional avalon and OSGi service support > > Roadmap: > * Release 2.3.2 now (after deprecating mordered, crypto) > * Release standard mailets 1.0 > * Release crypto mailets 1.1 targeting java 1.5 Make sense. > * Release 2.4 soon replacing source with jars released so far (with > note about standard mailets) > * Compiled against Java 1.5 > * Remove mordred > * Replace 2.x crypto source with released jar > * Replace 2.x mailet API with released jars > * Release 2.5 later replacing source with released jars > * Add jSPF support > * Replace standard mailet source with released jar > * Replace whichever other services have been released by then My main concern is that this does not give features to the users. Users are asking for a roadmap because they want easy virtualhosting, fastfail and other features that are in trunk since *3 years* (yes, some stuff was there when we released 2.3.0 and didn't land v2.3), are trunk specific, and backporting them is a PITA. I don't think that the roadmap above does worth the required work, but if anyone think so and is willing to work on that then it will not be a bad thing. The only real features for end users in that roadmap is jSPF and this could be released as a mailet anyway. jSPF as it is in trunk cannot be done in v2.3 because of different fastfail stuff (IIRC). I will not work and I will not use such a branch: I don't need any feature from that so why should I upgrade and risk bugs? IMHO the above roadmap is mainly a developer exercise to replace source code with libraries and to upgrade v2.3 to java5. Backporting stuff from 3.x to 2.x is simply unfeasible for most interesting code because we had to change interfaces and break some compatibility in order to support the new features. I BET backporting some of them will take *much* more time than testing trunk as a whole. People keep claiming that v2.3 is stable and trunk is not, but the fact is that simply no one tested trunk and confirmed it is unstable. Maybe it is, but until I'll see bug reports about instability against trunk I won't consider this. BTW this is only my opinion (as one of the developers that better know the differences between v2.3 and trunk). As I'm not going to work on any of that branches soon as I'm busy on different stuff, we should simply follow what active developers are willing to do. If you are interested in the roadmap above (and you find at least 2 more developers that will review the work you do) then I'm fine with that. Otherwise I don't find any interest in defining a roadmap that no one will take care to push. Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
