Dieter Maurer wrote: > Chris Withers wrote at 2006-6-14 07:32 +0100: >> ... >> Would be interested to know what other people think... > > I like time based releases but I hate deprecations > for "cosmetic annoyances" (term stolen from Andreas). > > I have the feeling that most deprecations so far > have been for "cosmetics" only.
Hmm, then we have different perspectives on why we would evolve (since evolvement is typically the cause of BBB code and hence deprecation warnings). I think there are two main driving factors: * cutting down the amount of code duplication and duplicated frameworks. We've had two ZPT implementations, now we have to maintain only one. We had our own logging framework, now we can simply use Python's, etc. These changes may seem cosmetic to the outside developer (he has to use different APIs), but they're essential to us as to how much code we want to have maintained or, in the worst case, bitrotting in our source tree. I'll note that even the outside developer may benefit from our using more standard libraries, because they might already been known to him. Even more so, they're already documented by someone else. (Was zLOG ever documented? I don't think so. But the 'logging' module is.) * moving to more Zope 3 technology. We've managed to introduce Zope 3 technology in a couple of isolated areas in Zope 2, e.g. i18n, views, object events. So far, we've only seen deprecation warnings in the field of events where the old manage_* methods have been deprecated. Zope 3's event system is superior to the methhod overriding in Zope 2, hence we're evolving Zope 2. People *want* to use Zope 3 technology in Zope 2 more and more and currently the framework it's stopping them in many ways. Five, on the other hand, is just a (very large by now) compatibility layer (with lots of code duplication) to which the first point shall also apply: we should try to make code in Five smaller by evolving Zope 2. I agree with Tres, Chris, Andreas and Dieter that we've seen some spurious deprecation warnings in the Zope 2.9 release. I think things got deprecated in Zope 2.9 that were scheduled for deprecation in Zope 2.10 (e.g. zLOG). There might have been other cases. I also agree that we can't deprecate anything as long as Zope code is still using it. I think there are some deprecation fouls like that in Zope 2.9, too. This was all unfortunate. What we can do about it now is fix it and learn from it for future release cycles. I also agree with Dieter on cosmetic annoyances. But I don't think we're deprecating only for cosmetics. I think a deprecation warning should satisfy at least one of the above points. Otherwise it wouldn't be worth it. Chris put this nicely, we need to pick our battles. I do stand behind evolving Zope 2 and exploring synergies with standard Python software. That's my battle :). Philipp _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org 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 )