Rob Miller wrote:
Jens Vagelpohl wrote:
On 12 Nov 2005, at 09:04, yuppie wrote:
GenericSetup is still a moving target. I would not create a branch for 1.6 before 2.0 has stabilized.

unfortunately i need to move rather quickly to be able to produce a proof-of-concept for the framework team to review. i may need to cut a branch and then just accept that i'll have to keep up w/ GenericSetup for a bit. do we know how much change is likely to happen, and in what areas?

Well. I'll try to summarize what comes to my mind. This doesn't include the things Tres is working on.

1.) GenericSetup is quite silent. We need a logging and reporting framework. There is the provisional 'note' method in ISetupContext, but it has an XXX comment and doesn't look mature.

I'm afraid nobody is working on this.

2.) We have to decide if we want to support more handler modes than shouldPurge false and shouldPurge true. Possible other modes could be 'dry run' or an 'append' mode that adds a copy with a different name instead of overwriting existing objects.

3.) The format of the XML files will change over time. I guess it would be useful to add version numbers to each exported XML file. This way it would be easier to do the right thing on import or to throw an error if the profile is too old. This could replace the version numbers of import steps.

4.) As soon as the first three issues are resolved we can adjust the node adapter API and freeze it. Instead of passing around additional arguments I'd like to make node adapters multi-adapters for the object and an export/import context.

This would be an important milestone because it would allow to write setup handlers that work with the final versions of CMF 1.6 and 2.0.

5.) There is my proposal for simplifying tool handlers:
I'm currently waiting for an answer from Florent.

6.) CMF 2.0 should no longer depend on CMFSetup. With a CMF 1.6 release that provides BBB for CMF 1.5 profiles we might even be able to remove CMFSetup completely in CMF 2.0. The remaining setup handlers should be modernized and moved to the related products.

There are also other unresolved issues, but I think freezing the API for setup handlers is the most important thing. Improving the setup tool and stuff like that could be done in CMF 2.1 if necessary.

Stabilized meaning moved from alpha to beta or the final? I'm trying to see how far the different schedules (Plone 2.2 and a stabilized GenericSetup) can be made to match up.

I would not like to do this work on different branches, but if GenericSetup is a SVN external or if someone else does the merging I'm fine with creating the 1.6 branch earlier. Anyway I don't think 1.6 can be released before 2.0.

We did have to break CMFSetup backwards compatibility more than once in CMF 1.5 releases because the CMFSetup shipped with 1.5.0 wasn't mature at all. I would not like to do the same with GenericSetup and CMF 1.6/2.0.

Don't know what Tres has on his ToDo list, but I guess we could need help with some tasks.



Zope-CMF maillist  -  Zope-CMF@lists.zope.org

See http://collector.zope.org/CMF for bug reports and feature requests

Reply via email to