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 _______________________________________________ Zope-Dev maillist - [email protected] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
