[Zope-dev] Re: PermissionGeddon

[Leonardo Rochael Almeida]

Hi Florent

Em Ter, 2005-11-29 às 15:32 +0100, Florent Guillaume escreveu:
> [...]
> 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?

They probably will change it, people don't like their code to generate
deprecation warnings. But the greatest beneficiaries of the deprecation
strategy are not the framework builders, but the users.

Suppose a Zope change breaks, say, Plone (to pick two arbitrary
examples :-). This means, that in order to upgrade to the next Zope
version, I need to upgrade Plone first. If Plone, on the other hand,
depends on Zope features that are only available in the newer Zope
version, I'm forced to upgrade both layers of my running site
simultaneously, making it much more expensive to calculate the migration
overhead and procedures.

I don't want to start a discussion about whose responsability is to keep
compatibility with what software, but I, for one, prefer to upgrade the
lower layers of my solutions before the upper layers if possible: Python
before Zope, Zope before Plone, Linux kernel before glibc. This is not
always possible, and there are loads of counter-examples, but if we can
avoid forcing the poor user to upgrade more than one piece of software
at a time, I think this is something we should try to achieve.

Cheers, Leo