[Zope-CMF] Re: backporting GenericSetup to CMF-1.5

[yuppie]

Hi!


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:
http://mail.zope.org/pipermail/zope-cmf/2005-November/023331.html
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.


Cheers,

	Yuppie