Re: [Zope-dev] Re: Time-based releases a good idea?
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-6-18 12:38 +0200: ... deprecation policy ... This policy allows us to move forward (which Zope 2 never really did for the the majority of those five years you mention). Although, it might help in a few cases, it is not at all necessary to cast ones history away when moving forward. I do not agree with you that Zope2 did not move forward in the past 5 years. I agree that currently it moves faster -- but not because you cast out things but because you move lots of new functionality in. +lots Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Philipp von Weitershausen wrote at 2006-6-18 12:38 +0200: ... deprecation policy ... This policy allows us to move forward (which Zope 2 never really did for the the majority of those five years you mention). Although, it might help in a few cases, it is not at all necessary to cast ones history away when moving forward. I do not agree with you that Zope2 did not move forward in the past 5 years. I agree that currently it moves faster -- but not because you cast out things but because you move lots of new functionality in. -- Dieter ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Dieter Maurer wrote: * 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. The second logging framework (zLOG) was a tiny wrapper around Python's logging -- no need to force changes by removing it. This is ok with me, but isn't currently part of our deprecation policy. I wouldn't mind changing our policy though. Either way, zLOG/__init__.py said since Zope 2.8: This module exists only for backward compatibility. Any new code for Zope 2.8 and newer should use the logging module from Python's standard library directly. So, raising the deprecation warnings in the first place was the right thing. Removing zLOG perhaps wasn't, but again, we should reevaluate our policy then. Even more so, they're already documented by someone else. (Was zLOG ever documented? I don't think so. But the 'logging' module is.) Its configuration was documented in the Zope schema file. Its single API method was self explaining... Not everybody is as smart as you are, Dieter. And certainly not everyone would get the idea of reading code or ZConfig schema files as documentation. 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 )
[Zope-dev] Re: Time-based releases a good idea?
Chris Withers wrote: Tres Seaver wrote: Unit test coverate for custom products is actually quite good. The problems are nearly always to do with third party products, many of which have been in useful stable mode since long before either deprectaions or ubiquitous unit testing were part of our community's development culture. Case in point: Squishdot hasn't seen any active maintenance in about 5 years, but it still worked fine up until zLOG disappeared and I started getting whine about 'methods'... So it still works fine in all stable Zope 2 releases. zLOG was only removed on the Zope trunk and methods is just a deprecation warning, apparently. You still have a couple of months left to fix it up and the deprecation warnings have already bugged you for several months in the past. The reason Squishdot has worked for five years is that Zope 2 never had a deprecation policy. Stuff was added and refactored, but old stuff wasn't deprecated. That isn't a big deal, but now we do have deprecation. This policy allows us to move forward (which Zope 2 never really did for the the majority of those five years you mention). 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 )
[Zope-dev] Re: Time-based releases a good idea?
Philipp von Weitershausen wrote at 2006-6-18 12:28 +0200: ... Its configuration was documented in the Zope schema file. Its single API method was self explaining... Not everybody is as smart as you are, Dieter. Thank you :-) And certainly not everyone would get the idea of reading code or ZConfig schema files as documentation. ZConfig schema files *are* (a lot of) documentation. Not looking there misses an essential, usually easy to grasp resource. The part of the schema/component concerning zLOG was definitely easier to grasp then the documentation of Python's logging module. If I do not write a logging call, then I will get enough understanding just by locking at the code and knowing how the log entries look like. No need to look into the source for this. A look into the source might help for writing ones own logging calls. -- Dieter ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Tres Seaver wrote: Unit test coverate for custom products is actually quite good. The problems are nearly always to do with third party products, many of which have been in useful stable mode since long before either deprectaions or ubiquitous unit testing were part of our community's development culture. Case in point: Squishdot hasn't seen any active maintenance in about 5 years, but it still worked fine up until zLOG disappeared and I started getting whine about 'methods'... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
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 )
[Zope-dev] Re: Time-based releases a good idea?
Tres Seaver wrote: Lennart Regebro wrote: On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: The time-based release cycle just amplifies this across many branches and point releases, so nobody really knows which products work with what branch/release and under what configuration some feature is supposed to emit a deprecation warning without a good deal of testing. The *reason* I'm stuck back on 2.8 and haven't upgraded the products I maintain to behave nicely on 2.9+ is because I just can't keep the fuck up with these sorts of changes. It's a self- perpetuating cycle because the only sane defensive maneuver for me is to stick with 2.8 for existing customer projects. I say to myself that I'll move them to 2.9 or 2.10, or 2.11, or whatever happens to be the current release once I get a chance to breathe, but honestly, this is the *last* thing I'll do; I've got plenty of other coding to do. Well, ignoring the confusion about zLOG, updating things for a new version of Zope with deprecation warnings is not much work. Honestly. You update to the new version, look at the depracation warnings, and do search/replace until they go away. Unless their are compatibility bugs, and that will happen sometimes, that's it. I don't remember exactly how long it took to go to 2.9 for CPS, but it wasn't very much work, and it was all related to changes in Five, which you don't seem to use or worry about. Bzzt. Five is a *major* culprit for us (Chris and I are often working together). The lookup order BBB foul in 2.9.2 is one of the major reasons for sticking to 2.8. I think we've been over this. It's not really a BBB foul because I classified it as a bug when I found out about the issue (http://codespeak.net/pipermail/z3-five/2006q1/001186.html). The rationale behind this thinking is being closer to Zope 3's behaviour where folder/foo would first look up the 'foo' item in the folder, then the @@foo view. I think we've also come to an agreement to make this pluggable. I don't remember anything happening, though. For all I care, we can go back to the old behaviour with the only exception that ObjectManagers are traversed attributes-first-views-later. Views should not shadow contained items. 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Lennart Regebro wrote: So this is not a problem with deprecation period, time based releases or anything else, then. No, but the slew of deprecation warnings, proliferation of branches that need to be supported (regardless of whether they're officially production or not) and sheer amount of change you now HAVE (rather than 'can choose') to deal with seems a sign, at least to me, that time-based releases were a nice experiment, but maybe it's time to think again? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Chris Withers wrote: Lennart Regebro wrote: So this is not a problem with deprecation period, time based releases or anything else, then. No, but the slew of deprecation warnings, proliferation of branches that need to be supported (regardless of whether they're officially production or not) and sheer amount of change you now HAVE (rather than 'can choose') to deal with seems a sign, at least to me, that time-based releases were a nice experiment, but maybe it's time to think again? I disagree completely. I think time based releases were a factor in rescuing at least Zope 2 from complete stagnation. I also think that time based releases have helped getting a lot more Zope 3 to everybody much faster than before. They have encouraged people to actually contribute to the core, as they know the fix or feature will be in there in a few months, at a predictable time, not years in the indefinitey future as it was before. Overall I think time based releases have been overwhelmingly *successful*. And yes, porting applications to new releases takes time and is frequently painful. If the alternative is stagnation or having to write code against old APIs that I know have better alternatives somewhere in subversion but don't know when they'll ever get released, I'll gladly take that pain. That said, of course things have to be done carefully. Stick with the release policy we all should be following anyway: don't deprecate anything in a bugfix release. Carefully consider backwards compatibility. Back out of changes that are too damaging. I'm curious to hear what alternative you'd prefer. I didn't like the old release policy much: from 2.6 to 2.7 took over a year and a half. The alpha for 2.7 was released almost a *year* before 2.7 was finally released. It then took a year for 2.8 to be released. Nobody knew what was going to happen when, and Zope 2 development was pretty stagnant for huge spans of time (not discounting the wonderful work that *was* done in that period). People were building piles of framework code on top of Zope that should've gone into the core where we could all share it, but people avoided the core. Now, Zope 2 is alive again. Regards, Martijn ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
On Jun 15, 2006, at 3:13 AM, Philipp von Weitershausen wrote: 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.) The zLOG removal will break far more third-party code than any other API change we've talked about so far. The cost of each API change needs to be weighed against its benefit. This is one of those cases where backwards compatibility was free; the code was already there. zLOG was just a tiny shim that called into the logging module. Removing it is gratuitous. In general, this change is the definition of cosmetic. For what it's worth, maybe there's some middle ground here. Just because something is deprecated doesn't need it needs to have a hard date to be removed. Why don't we just have the first use of zLOG in each module generate a deprecation warning and just leave it there forever? People will get sick of seeing the warnings, and they'll eventually change it, but there's just no reason to *force* them to change it on our time schedule. And if they don't, who cares? People who don't want to see the warnings can filter them out. I'm also for reducing duplication, but only to the point that it does not large amounts of break running code. We have yet to see what the real fallout of changing to the Z3 ZPT implementation is. It may be a pure win, but I wouldn't declare victory just yet, at least until we have some empirical evidence that it doesn't break large existing codebases. * 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. There are reasons we are bothering to change the Zope 2 APIs at this point instead of all of us moving to Zope 3 wholesale. One reason is because we've figured out that in the real world backwards compatibility and familiarity are primary drivers for take-up of technology. Let's please not forget that again, and let's be careful. - C ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Chris McDonough wrote: On Jun 15, 2006, at 3:13 AM, Philipp von Weitershausen wrote: 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.) The zLOG removal will break far more third-party code than any other API change we've talked about so far. The cost of each API change needs to be weighed against its benefit. This is one of those cases where backwards compatibility was free; the code was already there. zLOG was just a tiny shim that called into the logging module. Removing it is gratuitous. In general, this change is the definition of cosmetic. Well, except that the actual, formal deprecation of zLOG finally made everyone aware of the logging module and a few things like logging levels that no one had thought about till then. So I wouldn't say the benefit was exactly zero... whether it ways out agianst the costs I don't think I can say at this point. For what it's worth, maybe there's some middle ground here. Just because something is deprecated doesn't need it needs to have a hard date to be removed. Why don't we just have the first use of zLOG in each module generate a deprecation warning and just leave it there forever? Or make it available optionally. After all, it's just a Python module. Perhaps we should put up the latest version from Zope 2.10 as a separate egg on the cheeseshop. People can then just ez_install it if their product still happens to need it... People will get sick of seeing the warnings, and they'll eventually change it, but there's just no reason to *force* them to change it on our time schedule. And if they don't, who cares? People who don't want to see the warnings can filter them out. I'm also for reducing duplication, but only to the point that it does not large amounts of break running code. We have yet to see what the real fallout of changing to the Z3 ZPT implementation is. It may be a pure win, but I wouldn't declare victory just yet, at least until we have some empirical evidence that it doesn't break large existing codebases. Oh, I absolutely agree. Zope 2.10 will need strong testing mostly because the ZPT implementation. This was a pretty major change, the few heavy discussions we had so far already are good evidence of that (e.g. the one on empty path expressions). Given all that, it's still a thing we wanted to do and are happy to do. I agree, we can't declare victory on the whole war yet, but at least on a few battles... :) * 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. There are reasons we are bothering to change the Zope 2 APIs at this point instead of all of us moving to Zope 3 wholesale. One reason is because we've figured out that in the real world backwards compatibility and familiarity are primary drivers for take-up of technology. Let's please not forget that again, and let's be careful. I agree. This is why we need watch each other's steps and discuss the things. This has coined the term checkin police in Zope 3. We already have it in Zope 2, but somehow it has failed this time... This whole discussion has uncovered lots of stacked up frustration, it seems; it could have been held a lot earlier, I guess (from both sides). 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 )
[Zope-dev] Re: Time-based releases a good idea?
On 15 Jun 2006, at 16:09, Philipp von Weitershausen wrote: Chris McDonough wrote: People will get sick of seeing the warnings, and they'll eventually change it, but there's just no reason to *force* them to change it on our time schedule. And if they don't, who cares? People who don't want to see the warnings can filter them out. I'm also for reducing duplication, but only to the point that it does not large amounts of break running code. We have yet to see what the real fallout of changing to the Z3 ZPT implementation is. It may be a pure win, but I wouldn't declare victory just yet, at least until we have some empirical evidence that it doesn't break large existing codebases. Oh, I absolutely agree. Zope 2.10 will need strong testing mostly because the ZPT implementation. This was a pretty major change, the few heavy discussions we had so far already are good evidence of that (e.g. the one on empty path expressions). Given all that, it's still a thing we wanted to do and are happy to do. I agree, we can't declare victory on the whole war yet, but at least on a few battles... :) FWIW the CPS 4 trunk (in development for now) works fine with the new zpt implementation, provided you use only unicode everywhere, which we do. Thanks Philip for the move to z3 zpt! Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
On Jun 14, 2006, at 5:30 PM, yuppie wrote: Hi Chris! Chris McDonough wrote: On Jun 14, 2006, at 1:00 PM, yuppie wrote: It's not that simple. registerClass has an optional 'legacy' argument that does something quite similar. It just monkey patches ObjectManager instead of Folder. So at least for some use cases registerClass *will* help you. That would be helpful if I had a class to register. If I don't, it's an even worse hack than methods is. This is the case for External Editor. It has no addable types. And switching over to use something named legacy seems silly. How long until that's deprecated under the new clean-up-the-cruft-or-die regime? AFAICS the Right Way to modernize ZopeMailArchive and ExternalEditor would be using adapters. I don't recommend to abuse registerClass instead of 'methods'. And using a monkey patch is only the more obvious way of doing the wrong thing. OK. I still think this is wrong, but I don't have the time to argue anymore. I believe the Hippocratic Oath should be followed in subjective cases like this. First, do no harm. Cruft does harm. It discourages people who want to understand and improve Zope. And it encourages people to stick to bad coding habits. Nope. Sorry. It's the stinky glue that keeps everything running. I have a sense that you don't appreciate the full negative impact of these kinds of changes because you haven't really thought about the impact to the third-party dependency graph very much. If we do deprecate it, we will need to have the deprecation warning *at least* say something better than use registerClass, because that's meaningless. Maybe it should give a URL that has content that explains how to monkey patch OFS.Folder. But in that case, it just seems dumb to deprecate; we know methods works. Maybe we can provide a utility method that does the same thing as 'methods' does? Why do you want to have special support for monkey patching Folder? Which use cases justify to pollute the Folder API in that way? We can't rely on browser view lookup here. I'm will not break third- party code that relies on being able to look up EE's externalEditLink_ by asking for it against any folder via getattr. At least not when there's google hits for that string that point into silva, Zelenium, Axiom, Plone, CPS, and zpydoc. That would be dumb, because some of these products might not have even been updated to run against Zope 2.8+, and thus which would not be able to use Five even if they wanted to. So Florent has already changed EE on the trunk to do its own monkey- patch of Folder, which will stay. EE will start to break in 2.11 if I (or someone else) haven't gotten the time by then to make a new release of EE with that code. So be it. You ignored my argument regarding the shorter deprecation period. But if there is a consensus that old deprecations without explicit deprecation message don't count I'm fine with extending the period for __ac_permissions__ and meta_types as well. I did not mean to ignore it, I thought I had acknowledged it in another mail, sorry. No problem. And meanwhile you answered this in another mail. While I still believe there was a good reason to differentiate between new and historical deprecations I now see that it is hard to communicate the difference and all the confusion it caused is not worth the shorter warning period. So I'm fine with starting new deprecation periods for all code that was deprecated the old way (not using warnings). Of course new deprecation periods have to start in a .0 release. OK. - C ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
On Jun 15, 2006, at 10:09 AM, Philipp von Weitershausen wrote: Well, except that the actual, formal deprecation of zLOG finally made everyone aware of the logging module and a few things like logging levels that no one had thought about till then. So I wouldn't say the benefit was exactly zero... whether it ways out agianst the costs I don't think I can say at this point. If you can't say, it means you're not sure if there's a clear win, and if thats the case I think you gotta be on the side of not removing it under Hippocratic rules. For what it's worth, maybe there's some middle ground here. Just because something is deprecated doesn't need it needs to have a hard date to be removed. Why don't we just have the first use of zLOG in each module generate a deprecation warning and just leave it there forever? Or make it available optionally. After all, it's just a Python module. Perhaps we should put up the latest version from Zope 2.10 as a separate egg on the cheeseshop. People can then just ez_install it if their product still happens to need it... Yeah. Or just leave it in. ;-) There are reasons we are bothering to change the Zope 2 APIs at this point instead of all of us moving to Zope 3 wholesale. One reason is because we've figured out that in the real world backwards compatibility and familiarity are primary drivers for take-up of technology. Let's please not forget that again, and let's be careful. I agree. This is why we need watch each other's steps and discuss the things. This has coined the term checkin police in Zope 3. We already have it in Zope 2, but somehow it has failed this time... This whole discussion has uncovered lots of stacked up frustration, it seems; it could have been held a lot earlier, I guess (from both sides). Yup, see my mea culpa in my first message to this thread. I don't like needing to take a hard line on these issues, and I gotta admit to being extremely sympathetic to wanting to rip out all of this stuff in a perfect world, but my first allegiance is to my customers, who have completely different goals than the people who want rapid change. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Chris McDonough wrote at 2006-6-14 14:50 -0400: ... PsycoPG-DA does, MySQLDA does, one of my products named ZopeMailArchive does. CCSQLMethods does (because until very recently ZSQLMethods did, hopefully changed now). -- Dieter ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Andreas Jung wrote: At some point you have to make a cut to get rid of old crap. Fixing the zLOG issue is a straight forward approach with very little risks for the programmer and it won't take too much time..I don't see a major problem with that. Except that it hits a sore spot for open source right on the head. Products are developed for our customers, and they will keep working for those customers until they choose to upgrade. In my case, a single product often starts out as a tool for a single customer, that I then make available. Usually I get a lot of (unreasonable) change request that I ignore :-s, but no bug fixes at all. That is fair enough, as I don't fix many bugs in other peoples products. But the problem is that I don't fix bugs that doesn't exist for my customers. So deprecation warnings are ignored, until the product sponsor chooses upgrade. If this is how OSS generally works, as I expect, then deprecations will break stuff that just doesn't get fixed. And new user will find it impossible to get all the products they need to work together, in the latest version. But the problem is probably not the time based release, just that there is to few generations for deprecations. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science Phone: +45 66 11 84 94 Mobile: +45 29 93 42 96 ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-14-06 at 13:34 +0200, Lennart Regebro wrote: The majority has agreed that the path forward for Zope is to make it possible for people to use Zope3 technologies without having to rewrite everything from scratch. The changes you see in Zope2 are a direct effect of that. You should only get upgrade problems if you skip several versions. Other than that, it should pretty much just work. I'd just like to add that I agree with all points in this post. Plone is also in a very similar situation and it was quite minimal work getting from 2.8 to 2.9 and now to 2.10. The result is that Plone is now using more and more component architecture functionality which is making certain area's easier to maintain and is currently making things more fun to code :) As well, the switch to zope 3 technologies is enabling us reuse more zope tech so we have to develop less plone tech which is always a good thing. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On 6/14/06, Max M [EMAIL PROTECTED] wrote: But the problem is that I don't fix bugs that doesn't exist for my customers. So deprecation warnings are ignored, until the product sponsor chooses upgrade. Very reasonable. If this is how OSS generally works, as I expect, then deprecations will break stuff that just doesn't get fixed. I'm not sure I follow you here. Deprecations in themselves break nothing, of course, so I assume you mean that the changes break stuff that doesn't get updated. This is true, but that is true for any non-backwards-compatible change. And every single major Zope version have had some sort of non-backwards-compatible change. That is, in fact, the whole definition of the major version. Otherwise it would be a bugfix. :) And new user will find it impossible to get all the products they need to work together, in the latest version. This is true, and a problem. And the more modules you have the worse it gets, as you get big compatibility matrices going on. But there is only one answer to that, and that is to update the software. It doens't mean *you* have to do so. But somebody has, reasonably whoever needs the update. That's OSS. :) Things get REALLY complex if you try to keep several version bugfree at the same time, which I guess is one of the reasons Chris stays on 2.8 so far. He doesn't want to have two branches, one 2.8 and one 2.9 compatible, and keep them both bugfree. This is very reasonable, and the reason for the deprecation period. The deprecation period gives you, in effect, 18 months notice. After 18 months, in the worst case, the feature you used is not any longer in any supported version of Zope. I think that's very reasonable. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 14:09 +0200, Wichert Akkerman wrote: No matter what period we decide on it will always be too short for some and too long for others. With the current setup the deprecation period is a year, which seems like a decent middle ground. A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. Currently adding a deprecation in a release doesn't automatically equate to a year's grace period, because people seem to assume they can deprecate a feature in a very late point release of the current stable branch and deprecate it exactly two releases later. Which in a time-based cycle is always shorter than a year, because the point release of the stable branch happens concurrently with development of the next major release. - C ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Hi Chris! Chris McDonough wrote: On Wed, 2006-06-14 at 14:09 +0200, Wichert Akkerman wrote: No matter what period we decide on it will always be too short for some and too long for others. With the current setup the deprecation period is a year, which seems like a decent middle ground. A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. As the person who added the deprecation warning for 'methods': If you calculate the deprecation cycle from the day the warning was added I agree it is too short. Reading the sources I had the impression that the fact there was no warning for the deprecated feature was a bug and I did consider my change a bugfix. Without warning it was already deprecated for many years. I'm fine with extending the deprecation period by one more release cycle. Cheers, Yuppie ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Previously Chris McDonough wrote: A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. I haven't kept track of zLOG (I'm still new to this world) so I don't know if that went according to the normal schedule or not. Currently adding a deprecation in a release doesn't automatically equate to a year's grace period, because people seem to assume they can deprecate a feature in a very late point release of the current stable branch and deprecate it exactly two releases later. Which in a time-based cycle is always shorter than a year, because the point release of the stable branch happens concurrently with development of the next major release. If I understand this correctly the problem you are seeing is this that you develop against an unreleased Zope version, so worst case your deprecation period starts just before the first beta of release x when someone adds a deprecation and ends at the time trunk opens for development for release x+2 and the deprecated feature is removed, which can be 6 months. I don't think that's a very fair method of measuring deprecation time: for stable releases which almost everyone uses the deprecation time will have been the full year. Wichert. - -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 15:44 +0200, Wichert Akkerman wrote: Previously Chris McDonough wrote: A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. I haven't kept track of zLOG (I'm still new to this world) so I don't know if that went according to the normal schedule or not. Actually, it will (or at least pretty close), since we aren't removing it until 2.11 (I computed 6 months based on 2.10, sorry). If I understand this correctly the problem you are seeing is this that you develop against an unreleased Zope version, so worst case your deprecation period starts just before the first beta of release x when someone adds a deprecation and ends at the time trunk opens for development for release x+2 and the deprecated feature is removed, which can be 6 months. No, actually, that's not what I mean. I don't think that's a very fair method of measuring deprecation time: for stable releases which almost everyone uses the deprecation time will have been the full year. Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) vs. http://svn.zope.org/Zope/branches/Zope-2_8-branch/lib/python/OFS/Application.py?rev=39882r1=39762r2=39882 (fixup checkin made Nov. 4, 2005, the earliest checkin for these deprecations was Oct. 31 2005). I'm no math genius, but that sure seems like about 8 months to me end-to-end. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
--On 14. Juni 2006 10:40:05 -0400 Chris McDonough [EMAIL PROTECTED] wrote: Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) You know that the project wikis were always vapourware wikis (find it good or not)...lots of plans before the next release but only a small number of plans will make it into the final release. Likely the dates above were added before we changed to the June/December release cycle. -aj pgpOGKFkrurCx.pgp Description: PGP signature ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 15:42 +0200, yuppie wrote: If you calculate the deprecation cycle from the day the warning was added I agree it is too short. Whew, I'm not nuts then. ;-) Reading the sources I had the impression that the fact there was no warning for the deprecated feature was a bug and I did consider my change a bugfix. Without warning it was already deprecated for many years. That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. I'm fine with extending the deprecation period by one more release cycle. That's fine for __ac_permissions__ and meta_types, but can't we just leave 'methods' in? IMO, deprecating it was a simple mistake, and that's OK. We don't need to make another mistake by actually removing it for the sake of being consistent with the earlier mistake. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
So... you're saying that 2.10 isn't going to be released until December 2006, then? That would indeed make the deprecation period longer than 1 year, which seems to have been the intent. But wouldn't that make Zope's a yearly release cycle, given that the first beta of 2.9 was released *last* December? Now I'm really confused. On Wed, 2006-06-14 at 16:46 +0200, Andreas Jung wrote: --On 14. Juni 2006 10:40:05 -0400 Chris McDonough [EMAIL PROTECTED] wrote: Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) You know that the project wikis were always vapourware wikis (find it good or not)...lots of plans before the next release but only a small number of plans will make it into the final release. Likely the dates above were added before we changed to the June/December release cycle. -aj ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
--On 14. Juni 2006 10:59:09 -0400 Chris McDonough [EMAIL PROTECTED] wrote: So... you're saying that 2.10 isn't going to be released until December 2006, then? huh? The wiki says June/July...we are just running a bit late with the beta releases because Philikon needed some time for the ZPT integration..so why December? That would indeed make the deprecation period longer than 1 year, which seems to have been the intent. This makes no sense to me. Andreas pgpETOOh3GN7G.pgp Description: PGP signature ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 17:03 +0200, Andreas Jung wrote: --On 14. Juni 2006 10:59:09 -0400 Chris McDonough [EMAIL PROTECTED] wrote: So... you're saying that 2.10 isn't going to be released until December 2006, then? huh? The wiki says June/July...we are just running a bit late with the beta releases because Philikon needed some time for the ZPT integration..so why December? Buh oh geez, let's just forget it. ;-) That would indeed make the deprecation period longer than 1 year, which seems to have been the intent. This makes no sense to me. Let's start clean here. What interval of time is reasonable for the period between a to-be-removed piece of code emitting a deprecation warning and that code's removal? If you think 8 months is reasonable, it would make sense, for example, that the code in OFS.Application that looks for a module-scope '__ac_permissions__' in all products would be removed for 2.10 (as its deprecation warning currently states). If you think that's too short a time, then it's broken. Personally I think 8 months is too short a time, and I think it should be at least one year and I think most folks agree with this. I don't remember what the official policy is nor would I know where to find it. But if you agree with this, in order to have a full year's deprecation period, as far as I can tell, we'd need to make a policy that deprecations can only be done in in .0 releases. That would ensure at least a full year between the first deprecation and the code removal. Any other policy does not make sense if the goal is to have full-year-long deprecation periods. And at this point, IMO, a feature isn't really deprecated until it emits a warning. Older releases didn't emit deprecation warnings (partly because there was no warnings module), so basically *we tried not to deprecate anything* and we always strove (but only partially succeeeded) at full-bore backwards compatibility, cruft-be-damned. Things are better now, so we can deprecate stuff, but we still need to be consistent about how we do it. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. Ah, well, then we have two overlapping issues that causes this problemo: 1. We did not use deprecation warnings years ago. 2. methods issue deprecation warnings by mistake. (In fact, 2 is an effect of 1, as the warning comes because it was unclear what was deprecated.) This means that we in any case definitely should NOT remove methods until 2.11, if at all. :) So this is not a problem with deprecation period, time based releases or anything else, then. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Jun 14, 2006, at 12:32 PM, Lennart Regebro wrote: On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. Ah, well, then we have two overlapping issues that causes this problemo: 1. We did not use deprecation warnings years ago. 2. methods issue deprecation warnings by mistake. (In fact, 2 is an effect of 1, as the warning comes because it was unclear what was deprecated.) This means that we in any case definitely should NOT remove methods until 2.11, if at all. :) +1 to not at all from me ;-) So this is not a problem with deprecation period, time based releases or anything else, then. There are problems with the deprecation period, but only for __ac_permissions__ and meta_types assuming we choose not to deprecate 'methods'. If we were naive, we'd change the deprecation warning messages for __ac_permissions__ and meta_types in 2.9.4 from will disappear in 2.10 to will disappear in 2.11. But since we decided (in another offshoot of this thread) that it only makes sense to deprecate things in .0 releases, what *should* happen is that we should forget about all of this and add will disappear in 2.12 to what will become 2.10.0. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Jun 14, 2006, at 1:09 PM, Lennart Regebro wrote: On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: There are problems with the deprecation period, but only for __ac_permissions__ and meta_types assuming we choose not to deprecate 'methods'. The problem in this case being that we didn't use to issue deprecation warnings. ;) Yup, can't change history. In any case, I personally don't care if it's removed in 2.10 or 2.11. But since we decided (in another offshoot of this thread) that it only makes sense to deprecate things in .0 releases, what *should* happen is that we should forget about all of this and add will disappear in 2.12 to what will become 2.10.0. I don't understand that logic. Zope 2.9.0 issued deprecation warnings for these. Why should we not remove it in 2.11.0? That is two major versions later. You're right, sorry. I didn't realize the deprecations made it into 2.9.0; I thought they went in to 2.8.5+ and 2.9.1+ . Removing these in 2.11.0 is fine then. The 2.9 branch's deprecation warnings will continue to will say that all of these things will be removed in 2.10, which will be a lie. But that's OK, people will tolerate misleading deprecation warnings as long as what we do is actually more conservative than what it says we're going to do. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Paul Winkler wrote: On Wed, Jun 14, 2006 at 11:47:13AM -0400, Chris McDonough wrote: I think that's the sanest policy. So it's OK if bullshit gets called on people putting deprecation warnings into any .1, .2, etc through .9 releases, then? This seems like the only thing that can work. We can't expect people to upgrade to stable point releases (e.g. 2.8.5 from 2.8.4 or earlier) just to be able to see deprecation warnings. That makes perfect sense to me. +1 to no new deprecation warnings in stable third-dot releases. +1 to that too. No new deprecation warnings outside feature releases. Regards, Martijn ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Hi yuppie... On Jun 14, 2006, at 1:00 PM, yuppie wrote: Hi Chris! Chris McDonough wrote: On Wed, 2006-06-14 at 15:42 +0200, yuppie wrote: Reading the sources I had the impression that the fact there was no warning for the deprecated feature was a bug and I did consider my change a bugfix. Without warning it was already deprecated for many years. That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. It's not that simple. registerClass has an optional 'legacy' argument that does something quite similar. It just monkey patches ObjectManager instead of Folder. So at least for some use cases registerClass *will* help you. That would be helpful if I had a class to register. If I don't, it's an even worse hack than methods is. This is the case for External Editor. It has no addable types. And switching over to use something named legacy seems silly. How long until that's deprecated under the new clean-up-the-cruft-or-die regime? I might be wrong, but it looks like the 'legacy' argument was added exactly for that one purpose: Providing a migration path for 'methods'. I doubt it was ever good practice to use 'methods' for something else than factory methods. Don't know how many products out there use 'methods' for something else. But so far the only product mentioned is ExternalEditor. PsycoPG-DA does, MySQLDA does, one of my products named ZopeMailArchive does. Even in the core ZClasses/__init__.py still uses it. And these are only the products I have on my hard disk. No idea how many others use it. BTW: The name and comments in the code of the 'legacy' argument make clear that using these legacy methods is deprecated as well. I'm fine with extending the deprecation period by one more release cycle. That's fine for __ac_permissions__ and meta_types, but can't we just leave 'methods' in? IMO, deprecating it was a simple mistake, and that's OK. We don't need to make another mistake by actually removing it for the sake of being consistent with the earlier mistake. If adding deprecation warnings for 'methods' was a mistake it was not a simple mistake. I still believe it should be removed. I believe the Hippocratic Oath should be followed in subjective cases like this. First, do no harm. If we do deprecate it, we will need to have the deprecation warning *at least* say something better than use registerClass, because that's meaningless. Maybe it should give a URL that has content that explains how to monkey patch OFS.Folder. But in that case, it just seems dumb to deprecate; we know methods works. Maybe we can provide a utility method that does the same thing as 'methods' does? You ignored my argument regarding the shorter deprecation period. But if there is a consensus that old deprecations without explicit deprecation message don't count I'm fine with extending the period for __ac_permissions__ and meta_types as well. I did not mean to ignore it, I thought I had acknowledged it in another mail, sorry. - C ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Hi Chris! Chris McDonough wrote: On Jun 14, 2006, at 1:00 PM, yuppie wrote: It's not that simple. registerClass has an optional 'legacy' argument that does something quite similar. It just monkey patches ObjectManager instead of Folder. So at least for some use cases registerClass *will* help you. That would be helpful if I had a class to register. If I don't, it's an even worse hack than methods is. This is the case for External Editor. It has no addable types. And switching over to use something named legacy seems silly. How long until that's deprecated under the new clean-up-the-cruft-or-die regime? AFAICS the Right Way to modernize ZopeMailArchive and ExternalEditor would be using adapters. I don't recommend to abuse registerClass instead of 'methods'. And using a monkey patch is only the more obvious way of doing the wrong thing. I might be wrong, but it looks like the 'legacy' argument was added exactly for that one purpose: Providing a migration path for 'methods'. I doubt it was ever good practice to use 'methods' for something else than factory methods. Don't know how many products out there use 'methods' for something else. But so far the only product mentioned is ExternalEditor. PsycoPG-DA does, MySQLDA does, one of my products named ZopeMailArchive does. Even in the core ZClasses/__init__.py still uses it. And these are only the products I have on my hard disk. No idea how many others use it. The obsolete ZPsycopgDA 1.1 just uses it for factory methods, ZPsycopgDA 2.0 doesn't use it. The last ZMySQLDA release is 5 years old. It also uses it for factory methods. These 2 examples show that some very old products still use 'methods' instead of registerClass. They can easily be updated. ZClasses is no product and unless some other magic uses 'methods' it is ignored anyways. If adding deprecation warnings for 'methods' was a mistake it was not a simple mistake. I still believe it should be removed. I believe the Hippocratic Oath should be followed in subjective cases like this. First, do no harm. Cruft does harm. It discourages people who want to understand and improve Zope. And it encourages people to stick to bad coding habits. If we do deprecate it, we will need to have the deprecation warning *at least* say something better than use registerClass, because that's meaningless. Maybe it should give a URL that has content that explains how to monkey patch OFS.Folder. But in that case, it just seems dumb to deprecate; we know methods works. Maybe we can provide a utility method that does the same thing as 'methods' does? Why do you want to have special support for monkey patching Folder? Which use cases justify to pollute the Folder API in that way? You ignored my argument regarding the shorter deprecation period. But if there is a consensus that old deprecations without explicit deprecation message don't count I'm fine with extending the period for __ac_permissions__ and meta_types as well. I did not mean to ignore it, I thought I had acknowledged it in another mail, sorry. No problem. And meanwhile you answered this in another mail. While I still believe there was a good reason to differentiate between new and historical deprecations I now see that it is hard to communicate the difference and all the confusion it caused is not worth the shorter warning period. So I'm fine with starting new deprecation periods for all code that was deprecated the old way (not using warnings). Of course new deprecation periods have to start in a .0 release. Cheers, Yuppie ___ 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 )
