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... ;-).
-r
_______________________________________________
Zope-CMF maillist - Zope-CMF@lists.zope.org
http://mail.zope.org/mailman/listinfo/zope-cmf
See http://collector.zope.org/CMF for bug reports and feature requests
