Hi! What I'd expect from Zope 2.6 depends a bit on when Zope 3 will be available. If we are talking about a couple of months, I'd prefer only having bug fixes in 2.5.x (and no 2.6 at all). If we are talking about more than half a year, or even a year from now, things look different. The problem is that all time that is invested into Zope 2.6 will be lost for Zope 3 development, but on the other hand I can't imagine how I would convince a customer to fund Zope 3 development if the results will not be useable soon. So what we actually need is a Zope 2.5.x to 3 migration path and plan that justifies investments in either Zope 2.6 or Zope 3. For that, we'll have to answer a few questions, like - Are there any components in the Zope 3 development cycle that can be backported to the 2 series? - Can we build stuff into 2.6 that makes people start thinking the Zope 3 way? - ... I don't want Zope to end up like ArsDigita's ACS. They had a perfectly working 3 series that had all the features you'd expect, but was butt ugly in terms of the actual implementation. Then they started from scratch (like Zope is doing now) and built ACS 4, which was well-designed, but buggy as hell and had only core functionality. The plugins had not been ported yet. Then they started from scratch again and ported to Java (which Zope will not do I guess). Currently there are 500 or so freely available Zope add-ons on zope.org, which will most probably not work on Zope 3, at least not with the "3X" series. And there are even more non-free Zope products people have built on the 2 platform. I have the feeling that many of the add-ons will not be needed for Zope 3 because Zope 3 will do better out-of-the-box. But for many others there must be a migration path. Let's take the database adapters. If Zope 3 does not support the major databases from the beginning, it might not get the momentum it needs. Slightly off topic, I think what Zope (2 AND 3) need really urgently is another layer on top that delivers what the CMF (IMHO) did promise but not deliver to the extent I had expected: A solid foundation for Content Management Systems. This mainly means that we need an excellent DESIGN (i.e. API) on that level. Implementations may vary, but the interfaces should be as stable as possible. Some suggestions for that kind of design (which seems to be much easier to accomplish on the Zope 3 platform, which seems to have implemented some of that stuff already): - Storage should be completely separate from the data model. It should be possible to design a content class and then store it either in ZODB, the file system, an RDBMS or an LDAP server or whatever. - All the basic API (like "store", "delete", "edit", ...) must be free of HTTP specifics, so that I can modifiy content either over a web frontend or over WebDAV, FTP, ... - and even via a "fat client" application like a wxPython application. Currently that one is a mess. - On the HTTP end, skinning/chroming should work with ALL components. Imagine being able to create a design that works with Squishdot, CMF, and your own stuff out of the box, without having to change the implementation of the tools that are skinned. - The security API should really work. Currently there seem to be some really bad flaws with regard to checking for roles (and local roles). (I can go into details with that if somebody asks me and I find the time). - There should be a more rigid development model and tools to implement it. Currently it is hard for Zope developers to know where the business logic has to go. DTML really invited people to mix stuff, and ZPT seems a bit complicated to handle in terms of the actual syntax used. It isn't too readable either. Joachim