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
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
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