Jens Vagelpohl wrote:

On 20 Dec 2005, at 19:53, yuppie wrote:

The intention was to make things consistent. CMF 1.5 and CMF 2.0 have different ways to register custom type info classes. Before that change both machineries were broken on the 1.6 branch because they were merged in an insane way.

I fixed the new machinery because

- most code used already the new machinery (and I thought that was Rob's intention)

- this doesn't break many products

I don't mind if you switch the 1.6 branch back to the old machinery, but there are more changes necessary than just reverting the last checkin.

Like what exactly?

With all due respect, the 1.6 branch should *not* break stuff that works find on 1.5. The specific goal for 1.6 was to be "1.5 plus GenericSetup" so that it stays 1.5-compatible. This change has nothing to do with GenericSetup from all I can tell. Please don't just say "OK, change it back if you want, but there may be traps elsewhere". I do not know what all needs to be changed. I'll be happy to do it, but I need to know what else is involved.

yes, i believe the agreement was to try to keep 1.6 as close to 1.5 as possible, with the exception of GenericSetup. the types stuff is the greyest area, however, because the changes in the way TypeInfo objects are handled btn 1.5 and 2.0 has a considerable impact on the setup profiles and the import/export nodes. my original idea was to have the 1.6 types import adapter use the 2.0 style, containment-based profile format, but to generate 1.5 style TypeInfo objects. i haven't had time in recent weeks to keep up w/ all of the stuff that you've been doing, yuppie, but i do have a bit of concern that we're causing too much divergence btn 1.5 and 1.6 operationally. if we stray too far, then tres will stop forward-porting any 1.5 fixes that he might make... ;-).


Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to