Advertising

...

I hope to have tracked the ~200 failing tests down to two of your
changes in OFS.CopySupport.

The first change is in the manage_pasteObjects method of CopyContainer.
There are some _setObject and _delObject calls which grew a new
suppress_events parameter. This breaks the reference implementation of
Archetypes because it uses something based on BTreeFolder2 to store
references and BTreeFolder2 overwrites both _setObject and _delObject
with its own versions.

Several "Folder" like classes are likely to overwrite
"_setObject" and "_delObject".
Maybe, the code that calls these methods with an additional parameter
should be prepared to meet implementations that do not support
the extra parameter.

Ok, due to popular demand I'll make such a change.

I'm a bit peeved though at the lack of willingness from the few people that
have reimplemented their version of _setObject/_delObject (which could be
considered "private" APIs, seeing that they're prefixed with an underscore)
to just modify their code for forward compatibility and be done with it, but
instead have us embark in a year-long deprecation strategy.

This is supposed to be open source, can't we be reactive to change in such
situation? Are folks really going to ship their framework code with
_setObject unmodified from the current version when they ship it for Five
1.2 or Zope 2.9?