Noel J. Bergman wrote: > Norman Maurer wrote: > >>>> Personally, I'm ready to make it a release, and start work on 2.4, > which >>>> should be a careful selection of things to add, not a core dump from > trunk. >>> We never agreed on this roadmap. And I think I won't agree on this >>> approach even later. >> I agree with Stefano. For me we should use the current trunk as 2.4 >> ( with handler-api2 merged when its complete). I don't see any >> problems with it. We don't did "critical" changes which whould break >> compatibly. > > It should still be a careful selection. As I said long ago, if you want to > move trunk to 2.4, we should review every difference. Then, if we agree > that each one represents a suitable risk/reward, fine.
I'm sorry but (as I also said long ago) I'm on the opposite position about the 2.4 roadmap. We've just finished with a lot of efforts to put out a stable release to replace the old 2.2.0. 2.3.0 didn't introduce so much changes, but included a lot of fixes and a lot of refactoring useful for future improvements. Now I think that not only we should include everything we have now in trunk, but we should also define a period of feature development where we try to put in every cool feature we are able to develop in this time with one single restriction: keep storage compatibility. We kept storage compatibility between 2.2.0 and 2.3.0 and imho we can do the same for 2.3.0 to 2.4.0. config.xml will change, assembly.xml will change, maybe a few minor methods in the mailet apis could change. My proposal is to start at least 2 months of free development in trunk and then create the 2.4 branch to start the consolidation process. Considering that 2 months would be just before Christmas I would say let 's develop new features in trunk including the whole Christmas and we'll branch on the first days of 2007. Everything we currently have in trunk deserve inclusion in the next release and much more of this. We worked hard on 2.3 and I'm not ready and I'm not willing to start a new consolidation work just now. We have to look the long term also: I don't care if some of the feature we implemented in trunk will not be used by 2.4, I care that we use the next release also to consolidate that code so we'll be much more ready for 2.5 or 3.0. Furthermore I would consider a big mistake to try to release 2.4 as a 2.3 + new fastfail things, because new fastfail things are still in progress and not mature enough (we still have an incomplete branch with a fastfail-v2 attempt). I don't want to make another release where fastfail is again marked as "experimental" because we're still working on it. There is a lot of stuff that has been removed by the 2.3 branch but should really fit the 2.4 branch: database read/write streaming (we have write streaming in 2.3 but disabled by default because we had no time to test it enough), spool manager refactorings, 8bitmime (try again with new javamail fixes). We should refactor pop3 to follow the same smtp handlerchain pattern (and maybe do the same for remotemanager and nntp). We could try to include easier virtualhosting support, support for APOP and much other features that don't introduce storage incompatibility problems. Another thing is that we should wait for dnsjava 2.0.3 to include full SPF support and we should wait for javamail 1.4.1 to try to enable 8bitmime stuff again. A last reason to not start a 2.4 branch now and to not start a selective merge job is that we are not sure that 2.3.0 would not need a 2.3.1 release in a month and we should really avoid having 3 open branches (2.3, 2.4, trunk). Stefano --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
