OFS.Application deprecations for Zope 2.10
OFS.Application has a few deprecations warnings that were supposed to go away in Zope 2.10: __init__.py of %s has a long deprecated '__ac_permissions__' attribute. __init__.py of %s has a long deprecated 'meta_types attribute. __init__.py of %s has a long deprecated 'methods' attribute. Shall we remove them now? Note that ExternalEditors 0.9.1 for instance still used 'methods' but that's its own damn fault. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Jusst out of curiosity, what is the rationale for deprecating "methods"? - C On Jun 9, 2006, at 10:52 AM, Florent Guillaume wrote:
OFS.Application has a few deprecations warnings that were supposed to go away in Zope 2.10:
__init__.py of %s has a long deprecated '__ac_permissions__' attribute. __init__.py of %s has a long deprecated 'meta_types attribute. __init__.py of %s has a long deprecated 'methods' attribute.
Shall we remove them now? Note that ExternalEditors 0.9.1 for instance still used 'methods' but that's its own damn fault.
Florent
-- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
_______________________________________________ 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 )
I wasn't the one who did it, but the rationale is to remove all magic from things in __init__.py and use ZCML instead. Anyway for EE the 'methods' use can be replaced by: from OFS.Folder import Folder Folder.externalEdit_ = ExternalEditor() Folder.externalEditLink_ = EditLink Florent On 9 Jun 2006, at 17:41, Chris McDonough wrote:
Jusst out of curiosity, what is the rationale for deprecating "methods"?
- C
On Jun 9, 2006, at 10:52 AM, Florent Guillaume wrote:
OFS.Application has a few deprecations warnings that were supposed to go away in Zope 2.10:
__init__.py of %s has a long deprecated '__ac_permissions__' attribute. __init__.py of %s has a long deprecated 'meta_types attribute. __init__.py of %s has a long deprecated 'methods' attribute.
Shall we remove them now? Note that ExternalEditors 0.9.1 for instance still used 'methods' but that's its own damn fault.
-- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote:
Anyway for EE the 'methods' use can be replaced by: from OFS.Folder import Folder Folder.externalEdit_ = ExternalEditor() Folder.externalEditLink_ = EditLink
And this is supposed to be better?! Until a sane alternative is available, I'd proprose to un-deprecate these methods... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Florent Guillaume wrote:
Anyway for EE the 'methods' use can be replaced by: from OFS.Folder import Folder Folder.externalEdit_ = ExternalEditor() Folder.externalEditLink_ = EditLink
And this is supposed to be better?!
That's ExternalEditor's problem. At least the monkey patching is explicit, and in line with what the rest of __init__.py does. ExternalEditor is all about monkey patching.
Until a sane alternative is available, I'd proprose to un-deprecate these methods...
'methods' in __init__.py is not sane, it's big magic and nobody knows about it or how it works. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Hi Chris! Chris McDonough wrote:
Jusst out of curiosity, what is the rationale for deprecating "methods"?
It has been deprecated for at least 6 years now, I just added the warnings last year. I don't know the old discussions, but the comments added here make pretty clear that initialize() was meant to replace '__ac_permissions__', 'meta_types' and 'methods': http://svn.zope.org/Zope/trunk/lib/python/OFS/Application.py?r1=18170&r2=181... I guess 'methods' was never meant to be used for something else than factory methods. As Florent already pointed out using it for general monkey patching doesn't look like a good idea. We only can improve the product initialization if we first remove some cruft. Cheers, Yuppie
Right, sorry. I've been out of the loop. I haven't been keeping up with the latest goings on. FWIW, I recently needed to emulate this machinery for "Basket" so I can sympathize with wanting to make it saner, but I question the wisdom of deprecating 'methods'. IMHO, we should ignore the fact that the lookup for "methods" attrs comes after the comment that says "Support old-style product metadata". registerClass does not provide an automated way to do what "methods" does. The "new regime" way to do what it does would be to use a Five view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it? - C On Jun 12, 2006, at 6:57 AM, yuppie wrote:
Hi Chris!
Chris McDonough wrote:
Jusst out of curiosity, what is the rationale for deprecating "methods"?
It has been deprecated for at least 6 years now, I just added the warnings last year.
I don't know the old discussions, but the comments added here make pretty clear that initialize() was meant to replace '__ac_permissions__', 'meta_types' and 'methods': http://svn.zope.org/Zope/trunk/lib/python/OFS/Application.py? r1=18170&r2=18185
I guess 'methods' was never meant to be used for something else than factory methods.
As Florent already pointed out using it for general monkey patching doesn't look like a good idea. We only can improve the product initialization if we first remove some cruft.
Cheers,
Yuppie
I should note that the same rationale does not really apply to '__ac_permissions__' and 'meta_types'; what these do can be done in registerClass, so the deprecation warning isn't lying for those... - C On Jun 12, 2006, at 9:09 AM, Chris McDonough wrote:
Right, sorry. I've been out of the loop. I haven't been keeping up with the latest goings on.
FWIW, I recently needed to emulate this machinery for "Basket" so I can sympathize with wanting to make it saner, but I question the wisdom of deprecating 'methods'.
IMHO, we should ignore the fact that the lookup for "methods" attrs comes after the comment that says "Support old-style product metadata". registerClass does not provide an automated way to do what "methods" does. The "new regime" way to do what it does would be to use a Five view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it?
- C
On Jun 12, 2006, at 6:57 AM, yuppie wrote:
Hi Chris!
Chris McDonough wrote:
Jusst out of curiosity, what is the rationale for deprecating "methods"?
It has been deprecated for at least 6 years now, I just added the warnings last year.
I don't know the old discussions, but the comments added here make pretty clear that initialize() was meant to replace '__ac_permissions__', 'meta_types' and 'methods': http://svn.zope.org/Zope/trunk/lib/python/OFS/Application.py? r1=18170&r2=18185
I guess 'methods' was never meant to be used for something else than factory methods.
As Florent already pointed out using it for general monkey patching doesn't look like a good idea. We only can improve the product initialization if we first remove some cruft.
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 )
Chris McDonough wrote:
view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it?
Am I right as reading this as someone else who feels "why are we deprecating this just for the sake of it?" ? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Chris McDonough wrote:
view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it?
Am I right as reading this as someone else who feels "why are we deprecating this just for the sake of it?" ?
If you need monkey patching I don't see why the framework should help you. This should be extremely rare occurences with big comments, not use of a magic 'methods' class attribute. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florent Guillaume wrote:
Chris Withers wrote:
Chris McDonough wrote:
view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it?
Am I right as reading this as someone else who feels "why are we deprecating this just for the sake of it?" ?
If you need monkey patching I don't see why the framework should help you. This should be extremely rare occurences with big comments, not use of a magic 'methods' class attribute.
Removing it breaks longstanding and widely-used third-party products, which means that anyone upgrading will have to upgrade the products at the same time. The win in this case is mostly aesthetic, which makes the removal less attractive. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEjxdW+gerLs4ltQ4RAgn+AJ9vvrz2MW0n8LPFLUrBYF9HHGATcQCghIkm AW9iLTYZlySmRwH3m6Z6BC4= =Q7Ax -----END PGP SIGNATURE-----
On 13 Jun 2006, at 21:51, Tres Seaver wrote:
Florent Guillaume wrote:
Chris Withers wrote:
Chris McDonough wrote:
view, but this wouldn't work for non-URL lookups. So people who use 'methods' now will need to monkeypatch in hideous ways just like the 'methods' stuff does now, in which case why not leave it?
Am I right as reading this as someone else who feels "why are we deprecating this just for the sake of it?" ?
If you need monkey patching I don't see why the framework should help you. This should be extremely rare occurences with big comments, not use of a magic 'methods' class attribute.
Removing it breaks longstanding and widely-used third-party products, which means that anyone upgrading will have to upgrade the products at the same time. The win in this case is mostly aesthetic, which makes the removal less attractive.
Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. And this is only for Zope 2.10 which I doubt these third party products are using at the moment. If we don't remove things at some point, there's no point in doing deprecation warnings. We can push it back to Zope 2.11... Actually I really don't care, I've patched EE. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
On Jun 13, 2006, at 4:13 PM, Florent Guillaume wrote:
Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss.
You're right. This only because I haven't managed to get off 2.8 on any of my projects, so I just never see these warnings. The reason I haven't been able to make it off 2.8 is due mostly to other deprecation/feature addition aggressiveness that has taken place in 2.9 and on the HEAD. Us plain old folks just can't keep up. I really wouldn't at all mind releasing a patched EE if the thing being deprecated was worth deprecating. But IMO this was a bad deprecation, and we should just un-deprecate it.
If we don't remove things at some point, there's no point in doing deprecation warnings.
I think the deprecation shouldn't have been done in the first place. This is only about "methods" not about __ac_permissions__ and so on that have warnings in the file.
We can push it back to Zope 2.11... Actually I really don't care, I've patched EE.
Or we can just pretend we never deprecated 'methods', remove the warning, and get on with it; no harm, no foul. - C
On 14 Jun 2006, at 00:45, Chris McDonough wrote:
On Jun 13, 2006, at 4:13 PM, Florent Guillaume wrote:
Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss.
You're right. This only because I haven't managed to get off 2.8 on any of my projects, so I just never see these warnings.
The reason I haven't been able to make it off 2.8 is due mostly to other deprecation/feature addition aggressiveness that has taken place in 2.9 and on the HEAD. Us plain old folks just can't keep up.
I really wouldn't at all mind releasing a patched EE if the thing being deprecated was worth deprecating. But IMO this was a bad deprecation, and we should just un-deprecate it.
FWIW I patched EE's trunk on svn.zope.org.
If we don't remove things at some point, there's no point in doing deprecation warnings.
I think the deprecation shouldn't have been done in the first place. This is only about "methods" not about __ac_permissions__ and so on that have warnings in the file.
We can push it back to Zope 2.11... Actually I really don't care, I've patched EE.
Or we can just pretend we never deprecated 'methods', remove the warning, and get on with it; no harm, no foul.
Then the framework never gets cleaned up. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
FWIW I patched EE's trunk on svn.zope.org.
Thanks.
Or we can just pretend we never deprecated 'methods', remove the warning, and get on with it; no harm, no foul.
Then the framework never gets cleaned up.
So be it. This is really minor. Not deprecating it is the right thing, and I won't even qualify that with a "IMO" ;-) - C
Chris McDonough wrote:
So be it. This is really minor. Not deprecating it is the right thing, and I won't even qualify that with a "IMO" ;-)
+1 Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Wed, 2006-14-06 at 01:04 +0200, Florent Guillaume wrote:
Then the framework never gets cleaned up.
I'm actively learning Zope 2 core as much and as quickly as possible so I can become a more valuable contributor. The less "gunk" I have to learn about and understand the more quickly I'll become more valuable. I have to side with Florent on this one and say that there is an implicit goodness about removing "gunk" just because it is "gunk". And "gunk" that was deprecated should be ripe for removal. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm sympathetic to that. Change is hard, though and keeping existing code running is more important to the "Zope brand" than notional API cleanliness, and it's important to pick your battles. An example of cruft removal that is worthwhile: the help system code has stupid side effects (it writes to an invisible catalog in the ZODB *at startup!*), and people have an alternate way of viewing the help via the filesystem. Apparently nobody actually looks at the help system anyway, because if they did, they'd be complaining that it has content that's something like three major revisions behind. So that's a huge pile of cruft that could be ripped out, which would be a pure win. OTOH, I'd like nothing more than to get a do-over on sessions, but I won't get it. They have a nasty API. I'd rip that API out in a heartbeat if I didn't know it would screw lots of people. So I leave it because it's the right thing to do, clean or not. On Jun 14, 2006, at 6:55 AM, Rocky Burt wrote:
On Wed, 2006-14-06 at 01:04 +0200, Florent Guillaume wrote:
Then the framework never gets cleaned up.
I'm actively learning Zope 2 core as much and as quickly as possible so I can become a more valuable contributor. The less "gunk" I have to learn about and understand the more quickly I'll become more valuable. I have to side with Florent on this one and say that there is an implicit goodness about removing "gunk" just because it is "gunk". And "gunk" that was deprecated should be ripe for removal.
- Rocky
-- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net
_______________________________________________ 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 )
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFEj/CH8sgUgRRnf6URAm6EAKCgViLHPC7rczKAmsof/YwJpQbohQCeNRqT Mq1TGhlu5AMNhvLsLKQfls8= =j0fI -----END PGP SIGNATURE-----
Chris McDonough wrote:
An example of cruft removal that is worthwhile: the help system code has stupid side effects (it writes to an invisible catalog in the ZODB *at startup!*), and people have an alternate way of viewing the help via the filesystem. Apparently nobody actually looks at the help system anyway, because if they did, they'd be complaining that it has content that's something like three major revisions behind. So that's a huge pile of cruft that could be ripped out, which would be a pure win.
I dunno, I still find it handy for documentation for sequence.sort and DateTime, which I can never remember...
OTOH, I'd like nothing more than to get a do-over on sessions, but I won't get it. They have a nasty API. I'd rip that API out in a heartbeat if I didn't know it would screw lots of people. So I leave it because it's the right thing to do, clean or not.
Yeah, with you on this one... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Florent Guillaume wrote:
Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. And this is only for Zope 2.10 which I doubt these third party products are using at the moment. If we don't remove things at some point, there's no point in doing deprecation warnings.
This and things like it have been niggling me for a while now and I guess this finally prompted me to write a mail on it... I know the good reasoning behind the time-based releases, but have they really worked out? As someone else who never has enough time to "keep up" with releases I've found the introduction of time-based releases a generally negative thing. I don't say that lightly, they certainly sounded like a great idea when they were introduced but I've experienced more bugs, a helluva lot more pointless deprecation squeal and a lot more "upgrade fear" since this process was introduced. For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign. I dunno, it just feels like features are being rammed in and a _lot_ of stuff is being deprecated, sometimes without as much thought as should be given. Change for change's sake is never a good thing. As a result, I'm still mainly on a mix of Zope 2.7 and 2.8, and finally taking timid steps to 2.9 for some projects, all of which have required new versions of just about every add-on product. Now, this could all be seen as fair game, Zope _is_ going through a period of big and positive change as Zope 2 and Zope 3 converge, things like zLOG finally get put to rest and we move onto newer more powerful versions of python. If that's the case, then I hope we, as a community, "get there" at some point and can get back to focusing on the stability of the good ol' days. Would be interested to know what other people think... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
--On 14. Juni 2006 07:32:42 +0100 Chris Withers <chris@simplistix.co.uk> wrote:
Florent Guillaume wrote:
Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. And this is only for Zope 2.10 which I doubt these third party products are using at the moment. If we don't remove things at some point, there's no point in doing deprecation warnings.
This and things like it have been niggling me for a while now and I guess this finally prompted me to write a mail on it...
I know the good reasoning behind the time-based releases, but have they really worked out?
Yes and No. Yes: It's a must to have Zope 2 and Zope 3 in sync. Zope 2 development got a some more momentum again.. No: Half a yr is a short time. Major changes happened right short before the first beta release. Not all Zope users won't follow this fast release cycle.
For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign.
Deprecation warning is only annoying but not a bad sign. Deprecations are not a functional problem.
Now, this could all be seen as fair game, Zope _is_ going through a period of big and positive change as Zope 2 and Zope 3 converge, things like zLOG finally get put to rest and we move onto newer more powerful versions of python.
right...I did not think that we deprecated and removed something without having a reasonable replacement...or did we?
If that's the case, then I hope we, as a community, "get there" at some point and can get back to focusing on the stability of the good ol' days.
+1, +1, +1 Andreas PS @all developers: I hope you don't forget the bugday tomorrow :-))
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14 Jun 2006, at 09:44, Andreas Jung wrote:
--On 14. Juni 2006 07:32:42 +0100 Chris Withers <chris@simplistix.co.uk> wrote:
I know the good reasoning behind the time-based releases, but have they really worked out?
Yes and No.
Yes: It's a must to have Zope 2 and Zope 3 in sync. Zope 2 development got a some more momentum again.. No: Half a yr is a short time. Major changes happened right short before the first beta release. Not all Zope users won't follow this fast release cycle.
Yes, the 6 month cycle is very short. All of a sudden we have a situation where a whole slew of releases/branches is out there (2.7, 2.8, 2.9, 2.10, trunk) and I bet *no one* can say what's really supposed to be supported and what isn't. And if someone fixes a bug and wants to do "the right thing" by fixing it everywhere the effort keeps on growing. I think the 6 month number was picked as a good first guess how best to handle the new release process, and IMHO we should look at that again and adjust it.
For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign.
I think this is a dead horse now. Some things were deprecated without actually converting all instances where the deprecated code was in use. It's in your power to do something about it, go ahead. jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEj8idRAx5nvEhZLIRAjkEAJ4jP+C8Xus66FRbX5MNaoDPIIg7AwCguNYQ AyHinqF1uQnBQgmli2o4ANc= =r7+N -----END PGP SIGNATURE-----
--On 14. Juni 2006 10:28:08 +0200 Jens Vagelpohl <jens@dataflake.org> wrote:
For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign.
I think this is a dead horse now. Some things were deprecated without actually converting all instances where the deprecated code was in use. It's in your power to do something about it, go ahead.
Right. As a rule we must fix any code in the Zope core that would possibly spit out a deprecation warning caused by a deprecation warning. At least for zLOG in Zope 2.9 we (possibly only me) were not totally consequent. -aj
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warning: This is gonna be ranty and will almost certainly contain foul language. ;-) I've never actually seen a deprecation warning emitted for zLOG. And I'm about as "in the loop" as anybody could expect someone to be, but I've not actually worked on the core for maybe six months. This is because I've been trying to ship a long-term customer project, which we've settled on 2.8 for, and I haven't been keeping a close eye on the checkins list. Yes, I know. I know. I'm bad. But all of you have been there before, I'm pretty sure, so I hope you can sympathize. There was a message sent to the list about deprecating zLOG on January 8 of this year by Andreas, but it was supposed to have been deprecated in 2.10, not any 2.9 release, and was supposed to have gone away in 2.12, not in 2.11, as the currently 2.9 deprecation warnings for zLOG state. And why the should the core emit a deprecation warning? If the core uses it, it by definition shouldn't (*can't*) be deprecated. What's the goal here? Removing zLOG is (at least by any sane measure) totally gratuitous in the first place, we have conflicting reports about which version it's going to be deprecated in, and it's not even actually deprecated! This is the definition of a clusterfuck. Yes, I know. I should have spoken up earlier about zLOG. But to be honest I'm just barely keeping my head above water as it is, so I'm hoping to be able to trust that people make wise decisions about this sort of thing, and my main defense mechanism at this point is limited to covering my eyes and hoping everything will turn out ok. I'm hoping that people won't removing some random API for the sake of a hard-on over a Platonic ideal. Is that unreasonable? So, anyway, I have a really significant number of released products that make use of zLOG. I can't keep up with the release cycle, or the deprecations. These products will likely just be broken for new Zope releases and will emit warning messages for stable branches for some period of time. People are gonna be pissed. But there's not much I can do about it short of just giving up maintainership of those products to someone who is able and willing to keep up. There's only like, what, maybe 20 people who have demonstrated willingness to maintain the *core*, so it's a pretty fat chance of me finding one of those people to maintain my stuff. 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. There *have* to be other people in the same boat as I am. Speak up if so! Zope 2 is really just not the place to make sweeping innovations. We are losing working products as a result of these "innovations", and as a result, probably developers, and as a result of that, end users. In general we are being *way*, *way*, *way* too aggressive about deprecations and API changes in Zope 2. Sometimes you just need to live with your mistakes. I'd hope that people will try to be conservative in the future. For my part, I'll try to be more in the loop on that sort of stuff on the maillist and try to call bullshit more often and more on-time (mea culpa on that). - - C On Jun 14, 2006, at 4:39 AM, Andreas Jung wrote:
--On 14. Juni 2006 10:28:08 +0200 Jens Vagelpohl <jens@dataflake.org> wrote:
For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign.
I think this is a dead horse now. Some things were deprecated without actually converting all instances where the deprecated code was in use. It's in your power to do something about it, go ahead.
Right. As a rule we must fix any code in the Zope core that would possibly spit out a deprecation warning caused by a deprecation warning. At least for zLOG in Zope 2.9 we (possibly only me) were not totally consequent.
-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 )
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) iD8DBQFEj+lN8sgUgRRnf6URAn6DAKCLodMqkS2We7qQXmYIcaKbP1V++ACfRbwX CRvmMGvzEeyHQPWwwBFnwdM= =7oUS -----END PGP SIGNATURE-----
--On 14. Juni 2006 06:47:37 -0400 Chris McDonough <chrism@plope.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Warning: This is gonna be ranty and will almost certainly contain foul language. ;-)
You're allowed to do so :-)
There was a message sent to the list about deprecating zLOG on January 8 of this year by Andreas, but it was supposed to have been deprecated in 2.10, not any 2.9 release, and was supposed to have gone away in 2.12, not in 2.11, as the currently 2.9 deprecation warnings for zLOG state. And why the should the core emit a deprecation warning? If the core uses it, it by definition shouldn't (*can't*) be deprecated. What's the goal here? Removing zLOG is (at least by any sane measure) totally gratuitous in the first place, we have conflicting reports about which version it's going to be deprecated in, and it's not even actually deprecated! This is the definition of a clusterfuck.
Some comments in the zLOG module stated that it was intended to deprecate zLOG in Zope 2.8 afaik (not checking the sources right now). So I deprecated it in Zope 2.9 (without migrating all occurrences (mea culpa)...a cosmetic problem in my opinion) and it is now removed for Zope 2.11..
Yes, I know. I should have spoken up earlier about zLOG. But to be honest I'm just barely keeping my head above water as it is, so I'm hoping to be able to trust that people make wise decisions about this sort of thing, and my main defense mechanism at this point is limited to covering my eyes and hoping everything will turn out ok. I'm hoping that people won't removing some random API for the sake of a hard-on over a Platonic ideal. Is that unreasonable?
At least on the module level we did not remove something without a proper replacement.
So, anyway, I have a really significant number of released products that make use of zLOG. I can't keep up with the release cycle, or the deprecations. These products will likely just be broken for new Zope releases and will emit warning messages for stable branches for some period of time. People are gonna be pissed. But there's not much I can do about it short of just giving up maintainership of those products to someone who is able and willing to keep up. There's only like, what, maybe 20 people who have demonstrated willingness to maintain the *core*, so it's a pretty fat chance of me finding one of those people to maintain my stuff.
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.
There *have* to be other people in the same boat as I am. Speak up if so! Zope 2 is really just not the place to make sweeping innovations. We are losing working products as a result of these "innovations", and as a result, probably developers, and as a result of that, end users. In general we are being *way*, *way*, *way* too aggressive about deprecations and API changes in Zope 2. Sometimes you just need to live with your mistakes. I'd hope that people will try to be conservative in the future.
I agree almost with everything of that. However being conservative should not avoid making progress. This still raises the question: where shall be go with Zope 2. My theory is that Zope 3 will be the spare-part factory for Zope2 (please no beatings from the Zope 3 world :-)) and that Zope 2 will have a long life. This implies that we need to adopt more and more Z3 technology. Such integration will raise deprecation issue and possible...and it is our goal to minimize these issues. ...but that's only my personal theory. Andreas
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
Previously Max M wrote:
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.
But until then you don't upgrade and the changes made in later Zope versions are not relevant. If and when you do an upgrade you will have update your products to reflect that Zope (and other products) have evolved. That will always be true for upgrades.
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.
That's a fact of life and holds for non-OSS software just as well.
But the problem is probably not the time based release, just that there is to few generations for deprecations.
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. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Previously Max M wrote:
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.
But until then you don't upgrade and the changes made in later Zope versions are not relevant. If and when you do an upgrade you will have update your products to reflect that Zope (and other products) have evolved. That will always be true for upgrades.
Oh, I never meant to say that this was a problem for me. But I have a lot of released products that other people use. They are not able to use my products on new releases. Which will result in new users thinking that Plone products are broken from the get-go. -- 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
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
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
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
On 6/14/06, Chris McDonough <chrism@plope.com> 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/
On Jun 14, 2006, at 12:32 PM, Lennart Regebro wrote:
On 6/14/06, Chris McDonough <chrism@plope.com> 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
On 6/14/06, Chris McDonough <chrism@plope.com> 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. ;) 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. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Jun 14, 2006, at 1:09 PM, Lennart Regebro wrote:
On 6/14/06, Chris McDonough <chrism@plope.com> 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
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
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
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. 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. 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. 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. Cheers, Yuppie
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
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
yuppie wrote:
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.
As far as "methods" goes, I call bullshit on this. Simple documentation of what "methods" is used for probably would have sufficed...
Why do you want to have special support for monkey patching Folder? Which use cases justify to pollute the Folder API in that way?
This is Zope 2, namespace polution is _not_ something that's going to get fixed... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi Chris! Chris Withers wrote:
yuppie wrote:
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.
As far as "methods" goes, I call bullshit on this. Simple documentation of what "methods" is used for probably would have sufficed...
This is how 'methods' is documented in OFS.Application:: # Look for an 'initialize' method in the product. If it does # not exist, then this is an old product that has never been # updated. In that case, we will analyze the product and # build up enough information to do initialization manually. [...] # Support old-style product metadata. Older products may # define attributes to name their permissions, meta_types, # constructors, etc. [followed by the code that interprets the 'methods' attribute] So 'methods' is BBB code for constructors. Other use cases might work, but they were never officially supported. Note that using 'methods' was already 'old-style' 6 years ago.
Why do you want to have special support for monkey patching Folder? Which use cases justify to pollute the Folder API in that way?
This is Zope 2, namespace polution is _not_ something that's going to get fixed...
There were many attempts to fix this and the pollution would be much worse without those attempts. 'methods' was replaced by 'registerClass' to give constructors their own namespace: manage_addProduct. Cheers, Yuppie
yuppie wrote:
# Support old-style product metadata. Older products may # define attributes to name their permissions, meta_types, # constructors, etc. [followed by the code that interprets the 'methods' attribute]
So 'methods' is BBB code for constructors.
That depends on how you read the above. I'd say "methods" isn't deprecated ;-) (or, put differently, how do you provide functions needed by an "add" template? Squishdot has a need for this in obtaining a list of the available MailHosts) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Hi Chris! Chris Withers wrote:
yuppie wrote:
# Support old-style product metadata. Older products may # define attributes to name their permissions, meta_types, # constructors, etc. [followed by the code that interprets the 'methods' attribute]
So 'methods' is BBB code for constructors.
That depends on how you read the above. I'd say "methods" isn't deprecated ;-)
(or, put differently, how do you provide functions needed by an "add" template? Squishdot has a need for this in obtaining a list of the available MailHosts)
If these functions are only required by a specific template there is no need to add them to the global context. You can wrap the add form in a method and pass the functions (or better the result of the functions) as argument to the template. CMF's addConfiguredSiteForm does that e.g.: http://svn.zope.org/CMF/trunk/CMFDefault/factory.py?rev=68622&view=auto If the container allows to use views (by default that is not the case for generic Folders in Zope 2.9) there is a better solution: Use a Five view and add the functions to your view class. The ZCML version of registerClass allows to specify a Five view as add form. Cheers, Yuppie
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
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
yuppie wrote:
If adding deprecation warnings for 'methods' was a mistake it was not a simple mistake. I still believe it should be removed.
I think you're in the minority here. I suspect you could remove the "legacy" thing without much problem, but it feels like "methods" has a genuine need for existence...
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.
Sounds like a plan... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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 <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
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... (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
--On 14. Juni 2006 10:40:05 -0400 Chris McDonough <chrism@plope.com> 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
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 <chrism@plope.com> 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
--On 14. Juni 2006 10:59:09 -0400 Chris McDonough <chrism@plope.com> 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
On Wed, 2006-06-14 at 17:03 +0200, Andreas Jung wrote:
--On 14. Juni 2006 10:59:09 -0400 Chris McDonough <chrism@plope.com> 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
--On 14. Juni 2006 11:24:45 -0400 Chris McDonough <chrism@plope.com> wrote:
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?
The general rule for Zope 2 + 3: 1 year = 2 full major releases according the current half-yr schedule
If you think 8 months is reasonable,
I never said something like that. I even did not comment on the this issue since I have very little insight about the internals at this point. Anything deprecated in 2.9 can officially be removed in 2.11. It should not happen that a deprecation happens after the final release.
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.
See above..I fully agree..
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.
jup
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.
A feature should never be removed if there is no reasonable replacement. A feature should only be removed if it is obviously broken and unfixable, totally out-dated and unmaintable. Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
On Jun 14, 2006, at 11:35 AM, Andreas Jung wrote:
The general rule for Zope 2 + 3: 1 year = 2 full major releases according the current half-yr schedule
OK, good!
I never said something like that. I even did not comment on the this issue since I have very little insight about the internals at this point. Anything deprecated in 2.9 can officially be removed in 2.11. It should not happen that a deprecation happens after the final release.
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.
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.
See above..I fully agree..
Cool.
A feature should never be removed if there is no reasonable replacement. A feature should only be removed if it is obviously broken and unfixable, totally out-dated and unmaintable.
Don't be so hard on the help system. ;-) - C
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. One thing to clarify: would it be OK and even desirable to backport new deprecation warnings to the stable branch, *as long as* the deprecation period is still 1 year after the next .0 release? for example, if in the future a new deprecation warning is added in 2.11.0, with the feature to be removed in 2.13, we could add the same deprecation warning to 2.10.x bugfix releases? The advantage is that the deprecation warnings reach a wider audience of developers, giving them more lead time to fix their code. The disadvantage is that end users get more log spew about things they maybe can't fix, and that seems obnoxious to do in a stable branch. and it wouldn't make any sense at all if the deprecation requires you to replace the deprecated code with new features that don't even exist in the stable branch, e.g. because of a different Five version. OK, never mind, I think I've just convinced myself it's more trouble than help :) -- Paul Winkler http://www.slinkp.com
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
Martijn Faassen wrote:
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.
+ 1 too. One of my other bugbears is that a flood of deprecation warnings often masks real problems. How would people feel about the default zope.conf hiding all deprecation warning? Product authors should switch them on for their products, which they control, and they should need to worry about. This also applies for project-specific code. This seems a better place to me than the current default behaviour of "there's loads of these being spewed out, so I'll just ignore 'em all" which misses out on the last 2 things I mentioned above... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote: [snip]
One of my other bugbears is that a flood of deprecation warnings often masks real problems.
What real problems?
How would people feel about the default zope.conf hiding all deprecation warning?
-1 This is bad. You'd be making it far less likely people will worry about deprecations, and they'll end up fixing their code *after* the deprecation period when things actually break, instead of before.
Product authors should switch them on for their products, which they control, and they should need to worry about.
I wouldn't be against a way to selectively shut *down* deprecation warnings for products. I would do this only when I'm working on fixing deprecation warnings elsewhere and temporarily don't want to see them, or when I don't want to worry a customer.
This also applies for project-specific code.
This seems a better place to me than the current default behaviour of "there's loads of these being spewed out, so I'll just ignore 'em all" which misses out on the last 2 things I mentioned above...
Your response is quite different than mine. If my Zope spews out warnings at me I go and fix them. :) I really don't like applications that babble at me. Regards, Martijn
Martijn Faassen wrote:
Chris Withers wrote: [snip]
One of my other bugbears is that a flood of deprecation warnings often masks real problems.
What real problems?
Deprecation warnings in code I need to care about, as opposed to mindless spew from the zope core or other installed products but which i just use and don't have the knowledge to maintain...
This is bad. You'd be making it far less likely people will worry about deprecations, and they'll end up fixing their code *after* the deprecation period when things actually break, instead of before.
I'd assert most people don't worry about deprecation warnings because code still works when they see them. Oft overheard: "oh, just ignore them, stuff still works and someone will fix it later"
I wouldn't be against a way to selectively shut *down* deprecation warnings for products.
Warnfilters already let you do this...
Your response is quite different than mine. If my Zope spews out warnings at me I go and fix them. :) I really don't like applications that babble at me.
Believe it or not, I 100% agree with you, but other people don't feel the way. Both core zope and Plone spew forth in their default state. Yes, that's the fault of the people who didnt' fix deprecation warnings, but I still have to deal with it :-S Shutting up those "meaningless deprecations" is what I was driving at... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Both core zope and Plone spew forth in their default state.
Zope 2.10 does? It shouldn't. Please point out the deprecation warnings it sends. Also could we please bury the zLOG-was-only-halfwy-deprecated issue that's been beaten to death? Everybody knows there were spurious warnings from it in some past version. Everybody knows it's now been mea-culpa-ed and fixed. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote:
Chris Withers wrote:
Both core zope and Plone spew forth in their default state.
Zope 2.10 does? It shouldn't. Please point out the deprecation warnings it sends.
I, like many people I suspect, am still struggling to get projects onto 2.8/2.9. The thought that they're both going to be "obsolete" already fills me with dread :-(
Also could we please bury the zLOG-was-only-halfwy-deprecated issue that's been beaten to death?
Maybe once 2.9.4 is out and doesn't spew deprecation warnings? ;-) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Florent Guillaume wrote:
Chris Withers wrote:
Both core zope and Plone spew forth in their default state.
Zope 2.10 does? It shouldn't. Please point out the deprecation warnings it sends.
I, like many people I suspect, am still struggling to get projects onto 2.8/2.9. The thought that they're both going to be "obsolete" already fills me with dread :-(
Oh please, stop the FUD. Zope 2.9 is well within its normal release cycle and not going out of style for a long time. Andreas had the idea of phasing out Zope 2 releases one year after their first release, which would mean that Zope 2.8 would be phased out soon, but not yet. That still doesn't mean it's obsolete, it just means that there won't be any more bugfix releases. Given how many Zope 2.8 had and that there aren't many more fixes to be expected for it, I fail to see the problem with this. Plus, if you care to make more Zope 2.8 releases, by all means, do it. But don't burden Andreas with even more work when YOU once agreed to his very policy (see http://mail.zope.org/pipermail/zope-dev/2005-October/025556.html).
Also could we please bury the zLOG-was-only-halfwy-deprecated issue that's been beaten to death?
Maybe once 2.9.4 is out and doesn't spew deprecation warnings? ;-)
Fix it and stop complaining. This issue is dead. Philipp
Philipp von Weitershausen wrote:
Chris Withers wrote:
Florent Guillaume wrote:
Chris Withers wrote:
Both core zope and Plone spew forth in their default state. Zope 2.10 does? It shouldn't. Please point out the deprecation warnings it sends. I, like many people I suspect, am still struggling to get projects onto 2.8/2.9. The thought that they're both going to be "obsolete" already fills me with dread :-(
Oh please, stop the FUD.
Not FUD, whatever you mean by that here...
Zope 2.9 is well within its normal release cycle and not going out of style for a long time.
Well, 2.10 is about to be cut, no? That technically makes 2.9 "no longer supported", right? (in the same way that 2.8 is not currently the active maintenance branch...) If what we're really saying is that we've agreed to keep the previous two release branches maintained, then I assert we're branching too often ;-) (I think the linux model of 2.odd being dev and 2.even being stable (I may well have those the wrong way round) is designed to prevent excessive branching...
Andreas had the idea of phasing out Zope 2 releases one year after their first release, which would mean that Zope 2.8 would be phased out soon, but not yet.
I don't think there's enough clarity between when something is time based and when something is number based... And, in all honesty, a year is too short a period of time... 2 years is more realistic for most projects I've worked on.
Plus, if you care to make more Zope 2.8 releases, by all means, do it. But don't burden Andreas with even more work when YOU once agreed to his very policy (see http://mail.zope.org/pipermail/zope-dev/2005-October/025556.html).
Sometimes we learn from the past and our views on things change (still think implicit acquisition is a good idea? ;-) ). I'm certainly not trying to put any burden on Andreas, I'm questioning the policies which seem ot have resulted in so many branches that need maintaining...
Maybe once 2.9.4 is out and doesn't spew deprecation warnings? ;-)
Fix it and stop complaining. This issue is dead.
I'd prefer to see the person who caused all the deprecation warnings fix it.. (and I don't actually know who that is, before anyone thinks I'm having a personal dig...) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 6/26/06, Chris Withers <chris@simplistix.co.uk> wrote:
Oh please, stop the FUD.
Not FUD, whatever you mean by that here...
Right. FUD is when you intentionally spread unjustified Fear, Uncertainty and Doubt about things to hurt them. You don't. You may HAVE the above things, but if it is justified or not, it's definitely not FUD. :) (I'd say it's justified. Things are happening and happening quickly. It's completely justified to get spooked about that when you rely on stability).
Well, 2.10 is about to be cut, no? That technically makes 2.9 "no longer supported", right? (in the same way that 2.8 is not currently the active maintenance branch...)
No, 2.8 is in active maintenance. 2.8 will go out of active maintenance when 2.10 is cut.
(I think the linux model of 2.odd being dev and 2.even being stable (I may well have those the wrong way round) is designed to prevent excessive branching...
Maybe. It's designed to give you the ability to have resonable release numbers even for unstable branches, instead of calling it "alpha 1, 2, 3, 4" and "beta 1, 2, 3, 4". For me it doesn't make a difference. In fact, I prefer that it is expleicitly called "alpha" or "beta". The stable/unstable numbering scheme is useful if you have a ver long time, like years, betweeen stable releases. We didn't want that. Maybe that was wrong, but I don't think so. It's probably just as much a matter of taste as a matter of what you want out of Zope development.
I don't think there's enough clarity between when something is time based and when something is number based... And, in all honesty, a year is too short a period of time... 2 years is more realistic for most projects I've worked on.
Yes, but two years of what? Don't you think you will have found most bugs after the first year? And if you find more bugs, even after one year these can still be fixed. If they are easy to fix, you can do it. If they are fixed in later versions, somebody can most likely be easily convinced to backport them for a reasonable monetary contribution. If they are weird and obscure bugs that doesn't exist in later versions, or require huge changes in large parts of Zope, well, then you are going to have to switch versions *anyway*. I need to repeat this: Zope 2.7 did not disappear or stop working when Zope 2.9 was released. All that happened was that the people involved in active development of Zope said "right, we are no longer automatically backporting fixes to 2.7". That's is. That's all that happened. My personal sites run on Python 2.1.something and Zope 2.5. They did not explode or stop working When Zope 2.7 came out. 2.5 was released January 25th 2002. Is four years long enough? :) (I'm just nagging you now, don't take it seriously). If Zope would have been a closed source Microsoft software, I would have TOTALLY agreed with you. Because any problem that then pops up is dependant on the support of the company. When MS drops support for a version of software, that's pretty much the death of using that version in a serious project. But Zope is open source. Any problem that is there can be fixed, even if it is not longer "actively maintained".
Sometimes we learn from the past and our views on things change (still think implicit acquisition is a good idea? ;-) ). I'm certainly not trying to put any burden on Andreas, I'm questioning the policies which seem ot have resulted in so many branches that need maintaining...
Well, the only way to cut down on those branches is either to cut down on support of older versions (and you sure don't want that) or cut down the amount of new releases (and I sure don't want that). This means that we have a conflict of maintainability and development, and we need to find the right compromise. I'm not convinced that the current comprmise is not right. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Chris Withers wrote:
Philipp von Weitershausen wrote:
Chris Withers wrote:
Florent Guillaume wrote:
Chris Withers wrote:
Both core zope and Plone spew forth in their default state. Zope 2.10 does? It shouldn't. Please point out the deprecation warnings it sends. I, like many people I suspect, am still struggling to get projects onto 2.8/2.9. The thought that they're both going to be "obsolete" already fills me with dread :-(
Oh please, stop the FUD.
Not FUD, whatever you mean by that here...
I'm referring to your handwaving based on false information. "Dread" as you call it above is typically defined as the "anticipation of apprehension of fear" (Oxford American Dictionary). Spreading fear based upon false information is pretty close to FUD, I'd say.
Zope 2.9 is well within its normal release cycle and not going out of style for a long time.
Well, 2.10 is about to be cut, no? That technically makes 2.9 "no longer supported", right?
Nope. Zope 2.9 is in bugfix mode, at least for another 6 months and beyond that as long as people want to support it.
(in the same way that 2.8 is not currently the active maintenance branch...)
Still wrong. Zope 2.8 is still maintained. Andreas hasn't said anything yet about not making any more Zope 2.8 releases.
If what we're really saying is that we've agreed to keep the previous two release branches maintained, then I assert we're branching too often ;-)
(I think the linux model of 2.odd being dev and 2.even being stable (I may well have those the wrong way round) is designed to prevent excessive branching...
As Martijn pointed out already, this model makes it difficult to get features released at a definite point in time. Zope 2.7 and 2.8 were releases bloated with features that seemed to have taken forever. Zope 2.7 took more than two years. Zope 2.8 took more than one year and could be right up with Zope 2.7 if it hadn't been for Five.
Andreas had the idea of phasing out Zope 2 releases one year after their first release, which would mean that Zope 2.8 would be phased out soon, but not yet.
I don't think there's enough clarity between when something is time based and when something is number based...
I think there's lots of clarity. We make a major release every six months. That's the 'y' in x.y.z. Then the release managers may decide to make minor releases based on the number and necessities of bugfixes during the maintenance period. This is the 'z' in x.y.z.
And, in all honesty, a year is too short a period of time... 2 years is more realistic for most projects I've worked on.
Fine. Nobody said that we can't change this policy. BUT, just because you have Zope 2.7 in production doesn't mean we still need to actively maintain Zope 2.7. Of course, everyone's free to still do so if s/he needs bugfixes in there, but so far that hasn't happened. You're really the only one "complaining" so far, and actually haven't given any examples yet of where you see a problem with Zope 2.7 not being maintained anymore. Or Zope 2.8, for that matter (even though it still is).
Plus, if you care to make more Zope 2.8 releases, by all means, do it. But don't burden Andreas with even more work when YOU once agreed to his very policy (see http://mail.zope.org/pipermail/zope-dev/2005-October/025556.html).
Sometimes we learn from the past and our views on things change (still think implicit acquisition is a good idea? ;-) ). I'm certainly not trying to put any burden on Andreas, I'm questioning the policies which seem ot have resulted in so many branches that need maintaining...
Sure, we all change our views. I think the number of branches isn't a problem, though. They seem to retire themselves pretty quickly (about a year after the initial stable release). Philipp
Chris Withers wrote:
Both core zope and Plone spew forth in their default state.
the deprecation warnings in Plone annoy me to no end. unfortunately, though, Plone (thus far) has chosen to straddle Zope release. i can't fix the deprecation warnings that Plone 2.5 generates with Zope 2.9, for instance, because that would cause Plone to no longer work w/ the Zope 2.8 series. there is talk of having Plone 3 only support Zope 2.10; if this happens, then i suspect we'll no longer see deprecation warnings in a default Plone setup. -r
Rob Miller wrote:
Chris Withers wrote:
Both core zope and Plone spew forth in their default state.
the deprecation warnings in Plone annoy me to no end. unfortunately, though, Plone (thus far) has chosen to straddle Zope release.
I dunno... some, like zLOG, have been "fixable" since at most 2.7.0..
i can't fix the deprecation warnings that Plone 2.5 generates with Zope 2.9, for instance, because that would cause Plone to no longer work w/ the Zope 2.8 series.
...but I have a lot of sympathy with this and brings me back to the point I raised about the proliferation of versions... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2006-6-19 14:17 +0100:
... How would people feel about the default zope.conf hiding all deprecation warning?
I would not like it...
... This seems a better place to me than the current default behaviour of "there's loads of these being spewed out, so I'll just ignore 'em all" which misses out on the last 2 things I mentioned above...
I must admit (as you expect) that I usually ignore deprecation warning (I find most of them stupid). However, hiding them in the first place would not make things better ;-) -- Dieter
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris McDonough wrote:
On Wed, 2006-06-14 at 17:03 +0200, Andreas Jung wrote:
--On 14. Juni 2006 10:59:09 -0400 Chris McDonough <chrism@plope.com> 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.
+1. A deprecation is a change in the feature set, which is *not* appropriate in third-dot releases: those releases have stability as a primary goal; cleanliness is *not* next to godliness in that context.
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.
Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkC8w+gerLs4ltQ4RAlKVAKDDTlVZj4iUT7ZZzSiN7SoCS05TfwCgjcEl Hh6RL4+6bAV4kAJPkMY1emM= =LiMJ -----END PGP SIGNATURE-----
On 6/14/06, Chris McDonough <chrism@plope.com> 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'.
zLOG got deprecated for the use of logging in 2.7 if I remember correctly. In 2.8 zLOG became just a wrapper around the logging module. The warnings were not added until 2.9.1, which was released in February. It will be removed in 2.11.0, scheduled for January I think? It's a shame warnings weren't added before, but before we started with the time based releases, deprecations were done via the CHANGE log. :-) The OFS.Application thingies have been deprecated for ages. This is just like with zLOG, but worse, it has been deprecated but we didn't add any kind of deprecation warnings AT ALL back in the stone age. :) The warnings has been there since 2.8.5, which indeed is only half a year. So maybe that should not be removed until 2.11.0, then? -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Wichert Akkerman wrote:
Previously Max M wrote:
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.
But until then you don't upgrade and the changes made in later Zope versions are not relevant. If and when you do an upgrade you will have update your products to reflect that Zope (and other products) have evolved. That will always be true for upgrades.
Okay, 2 point: 1. That's all well and good until you _need_ some feature like MVCC and are then forced to do an upgrade which breaks prettymuch every one of your products. 2. Yeah, we all know that bugs should get fixed on all stable branches, but that becomes less and less likely the more stable branches there are. Time based releases seem to be making this problem much much worse. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 6/15/06, Chris Withers <chris@simplistix.co.uk> wrote:
2. Yeah, we all know that bugs should get fixed on all stable branches, but that becomes less and less likely the more stable branches there are. Time based releases seem to be making this problem much much worse.
Only because we have more stable releases, now than we had during 2002-2005. That in turn was because the development effort was directed at Zope3 during this period. Before that, we has stable releases around twice a year too: Between 2.1 and 2.2 there was 225 days Between 2.2 and 2.3 there was 196 days Between 2.3 and 2.4 there was 178 days Between 2.4 and 2.5 there was 186 days Between 2.5 and 2.6 there was 266 days All pretty much once every six months. What happened then, during 2.6 to 2.8 was that the development of Zope was done on Zope3, and Zope2 development suffered from this. So this is not a fault of time based releases. The difference is this:
1. That's all well and good until you _need_ some feature like MVCC and are then forced to do an upgrade which breaks prettymuch every one of your products.
And the difference is that this didn't happen very often during 2.6 to 2.8, because there were no new features to _need_. That's not a good thing. Zope2 development stood pretty much still for several years. We are no picking up the slack, and yes, that means loads of rapid changes. The alternative is stagnation and ultimately death. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro wrote:
Zope2 development stood pretty much still for several years. We are no picking up the slack, and yes, that means loads of rapid changes. The alternative is stagnation and ultimately death.
Well, I must say that I enjoyed that. Being able to add new functionality in peace, instead of fixing already working stuff. But then again, my interrest is in user functionality. Not in core development. -- 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
Lennart Regebro wrote:
Only because we have more stable releases,
"only"? That's the big problem here ;-)
1. That's all well and good until you _need_ some feature like MVCC and are then forced to do an upgrade which breaks prettymuch every one of your products.
And the difference is that this didn't happen very often during 2.6 to 2.8, because there were no new features to _need_. That's not a good thing. Zope2 development stood pretty much still for several years. We are no picking up the slack, and yes, that means loads of rapid changes. The alternative is stagnation and ultimately death.
I'm not sure I agree. Feature complete and stable is where most frameworks want to be. I'd suggest that constant churn and _need_ for upgrades is the way to ultimately die ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 6/14/06, Max M <maxm@mxm.dk> 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/
Max M wrote:
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.
Exactly. And having to go to much more effort to get a product working with a 3 or 4 "stable" branches is just too much damned work. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 6/14/06, Chris McDonough <chrism@plope.com> 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. 2.10 seems to have been even less, excepting two bugs in the 2.10 beta. And we do this move for CPS during the beta phase, which one typically shouldn't do. Normally you should get rid of the 2.9 deprecation warnings when you no longer want to support 2.8. Whi typically would be right about after 2.10 is released and 2.8 no longer is officially maintained. If you get rid of all deprecation warnings for 2.10 now, your software may very well stop working on 2.9. ;) Admittedly, now when I think about it, this assumes you have tests for the products that have reasonable coverage. If you don't it's much worse, because you have to test the whole product manually to get rid of all warnings. When you have tests, you are 99% sure things are fine once the warnings are gone.
There *have* to be other people in the same boat as I am.
Yeah, I was in the same boat with EasyPublisher, when Zope moved from python 1.5.2 to python 2.something. EasyPublisher stopped working. We felt stressed, and did not switch Zope version for a while, staying on, I think, 2.3, while everybody else went to 2.5. Remember, there was no real deprecation period then, each major version would simply have a set of incompatibilities. The result was that the longer we waited we had more and more Zope 2.3 bugs to work around, and while 3rd party products increased in version we had to use old versions because we were on an old zope version. So the longer we waited, the greater became not only the upgrade work, but the work of circumventing bugs and misfeatures in the old software. When I finally DID switch, it still was only a couple of days work, and it solved several of our problems. The changes was done for a reason, mostly. We *should* have kept up to date continously. It would have been less work for us.
Zope 2 is really just not the place to make sweeping innovations.
You are welcome to stay on 2.8 forever if you want. Or 2.7 for that matter, it doesn't include Five and so has a much smaller tgz. ;) I think alot has been done wrong when it comes to how the innovation known as Zope3 has been handled. But I don't think making those innovations available to Zope2 is a mistake. I also don't think it's a mistake to get rid of the amazing code-duplication that Zope2 and Zope3 together holds. Almost the only component that is not duplicated is the ZODB. Why should we have two publishers to maintain? And two webservers with two WebDav implementations and two of everything else? 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. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
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
On Wed, 2006-06-14 at 13:34 +0200, Lennart Regebro wrote:
On 6/14/06, Chris McDonough <chrism@plope.com> wrote: 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.
I realize it's easy to forget, because I'm clearly no genius, but I do write Zope software for a living, so updating to new versions of things is something I've dealt with in the past.
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.
Oh, geez. I maintain a large Five-using product. It may be one of the largest in existence (which is not meant as bragging, it's just probably true). It's currently 31,000 lines of Python, most of which is in browser views, another 12,000 lines of ZPT, and about 3000 lines of SQL. Therefore, I do have a stake in reasonably-recent Zope releases. There are others like me who maintain large 3rd-party code bases that actually depend on this stuff who aren't actively involved in the development of all of the pieces of the framework. These sorts of people just can't afford to upgrade in lockstep with the various current release cycles. These are the people I'd like to avoid pissing off. FWIW, I can actually deal with the churn, I'm not going anywhere anytime soon, but I can imagine not sticking around and ditching Zope for something more stable if I were less involved.
Admittedly, now when I think about it, this assumes you have tests for the products that have reasonable coverage. If you don't it's much worse, because you have to test the whole product manually to get rid of all warnings. When you have tests, you are 99% sure things are fine once the warnings are gone.
The product I speak of above has 700 individual unit tests and still has bugs. Shrug. I expect some breakage, and the tests will catch most of them, and that's fine. But I also have maybe five or six open source products that I maintain which don't see attention every week or even every month or sometimes every six months, because I'm working on other stuff. These are problematic for me to keep in sync, which causes problems for other folks.
When I finally DID switch, it still was only a couple of days work, and it solved several of our problems. The changes was done for a reason, mostly. We *should* have kept up to date continously. It would have been less work for us.
But really, in honest-to-god reality, you probably couldn't have while simultaneously serving your customers' immediate best interests. That's of course a subjective judgment, but at least think it over a little before saying you could have.
Zope 2 is really just not the place to make sweeping innovations.
You are welcome to stay on 2.8 forever if you want. Or 2.7 for that matter, it doesn't include Five and so has a much smaller tgz. ;)
Thanks for giving me your permission to do that.
I think alot has been done wrong when it comes to how the innovation known as Zope3 has been handled. But I don't think making those innovations available to Zope2 is a mistake.
Me neither. None of what I'm talking about has yet been related to Five. The two things that have brought this up in my mind so far have been the deprecation of 'methods' in __init__.py and the zLOG clusterfuck. Those things have nothing to do with Five or Zope 3.
I also don't think it's a mistake to get rid of the amazing code-duplication that Zope2 and Zope3 together holds. Almost the only component that is not duplicated is the ZODB. Why should we have two publishers to maintain? And two webservers with two WebDav implementations and two of everything else?
One good reason: because the old one works and hundreds if not thousands, if not tens of thousands already use it, and there is *no immediate benefit* for them to switch to something different.
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 majority has been pretty sheltered so far, IMO. I'm still struggling to explain the concept of *Python scripts* to some of my customers.
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.
So "don't worry about it" is your opinion? I don't think that's a reasonable position. But then again, what do I know, I'm only a dumb end user I suppose. And who wants all those pesky end users anyway? - C
--On 14. Juni 2006 08:23:53 -0400 Chris McDonough <chrism@plope.com> wrote:
The product I speak of above has 700 individual unit tests and still has bugs. Shrug. I expect some breakage, and the tests will catch most of them, and that's fine. But I also have maybe five or six open source products that I maintain which don't see attention every week or even every month or sometimes every six months, because I'm working on other stuff. These are problematic for me to keep in sync, which causes problems for other folks.
You will always have this migration risk. The risk increases with the number of frameworks you use. This also happened lately with my current Plone project where the CUstomiziationPolicy API disappeared without deprecation in Plone 2.5 which is currently a blocker to upgrade from 2.1 to 2.5. -aj
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:
On 6/14/06, Chris McDonough <chrism@plope.com> 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.
2.10 seems to have been even less, excepting two bugs in the 2.10 beta. And we do this move for CPS during the beta phase, which one typically shouldn't do. Normally you should get rid of the 2.9 deprecation warnings when you no longer want to support 2.8. Whi typically would be right about after 2.10 is released and 2.8 no longer is officially maintained. If you get rid of all deprecation warnings for 2.10 now, your software may very well stop working on 2.9. ;)
Admittedly, now when I think about it, this assumes you have tests for the products that have reasonable coverage. If you don't it's much worse, because you have to test the whole product manually to get rid of all warnings. When you have tests, you are 99% sure things are fine once the warnings are gone.
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.
There *have* to be other people in the same boat as I am.
Yeah, I was in the same boat with EasyPublisher, when Zope moved from python 1.5.2 to python 2.something. EasyPublisher stopped working. We felt stressed, and did not switch Zope version for a while, staying on, I think, 2.3, while everybody else went to 2.5. Remember, there was no real deprecation period then, each major version would simply have a set of incompatibilities. The result was that the longer we waited we had more and more Zope 2.3 bugs to work around, and while 3rd party products increased in version we had to use old versions because we were on an old zope version. So the longer we waited, the greater became not only the upgrade work, but the work of circumventing bugs and misfeatures in the old software.
When I finally DID switch, it still was only a couple of days work, and it solved several of our problems. The changes was done for a reason, mostly. We *should* have kept up to date continously. It would have been less work for us.
Zope 2 is really just not the place to make sweeping innovations.
You are welcome to stay on 2.8 forever if you want. Or 2.7 for that matter, it doesn't include Five and so has a much smaller tgz. ;)
I think alot has been done wrong when it comes to how the innovation known as Zope3 has been handled. But I don't think making those innovations available to Zope2 is a mistake. I also don't think it's a mistake to get rid of the amazing code-duplication that Zope2 and Zope3 together holds. Almost the only component that is not duplicated is the ZODB. Why should we have two publishers to maintain? And two webservers with two WebDav implementations and two of everything else?
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.
Deprecating something in Zope2 has to be a net win, where the real costs are part of the calculation. What we have been arguing about here is how to evaluate the costs (e.g., breaking otherwise working installed products) vs. the benefits (e.g., improving "code cleanliness"). This issue gets particularly sharp when the people evaluating the tradeoff don't pay the costs themselves (in this example, they don't depend on the products which break). Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEkDEi+gerLs4ltQ4RAsM2AKCTA6fxkC8A9gYIFbvF/2yY+V91cwCfblYg UpQJSPOcSmdCuOR/DxhmUE8= =78aq -----END PGP SIGNATURE-----
Tres Seaver wrote:
Lennart Regebro wrote:
On 6/14/06, Chris McDonough <chrism@plope.com> 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
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
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
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
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
Chris McDonough wrote:
checkins list. Yes, I know. I know. I'm bad. But all of you have been there before, I'm pretty sure, so I hope you can sympathize.
...and how!
And why the should the core emit a deprecation warning?
Amen.
the goal here? Removing zLOG is (at least by any sane measure) totally gratuitous in the first place,
Actually, I don't agree, zLOG is a PITA...
So, anyway, I have a really significant number of released products that make use of zLOG.
Loose 'zLOG', sub in a generic X for some feature I've relied on (History copy, etc) and I'm totally with you...
I can't keep up with the release cycle, or the deprecations. These products will likely just be broken for new Zope releases and will emit warning messages for stable branches for some period of time. People are gonna be pissed.
Ditto.
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.
Amen, again...
There *have* to be other people in the same boat as I am. Speak up if so! Zope 2 is really just not the place to make sweeping innovations. We are losing working products as a result of these "innovations", and as a result, probably developers, and as a result of that, end users. In general we are being *way*, *way*, *way* too aggressive about deprecations and API changes in Zope 2. Sometimes you just need to live with your mistakes.
*rounds of cheering* Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Andreas Jung wrote:
Right. As a rule we must fix any code in the Zope core that would possibly spit out a deprecation warning caused by a deprecation warning. At least for zLOG in Zope 2.9 we (possibly only me) were not totally consequent.
Yes, I noticed your name in "svn praise" ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Jens Vagelpohl wrote:
Yes, the 6 month cycle is very short. All of a sudden we have a situation where a whole slew of releases/branches is out there (2.7, 2.8, 2.9, 2.10, trunk)
Indeed, this seems to be purely an artifact of time-based releases. I'm sure I'm not the only one who routinely has projects that see no maintenance for over a year, and doesn't like moving major zope versions without a compelling reason. The hops most of my projects seemed to have made are 2.5->2.6-->2.7->2.9, but I'm only just getting onto 2.9 and people are talking about 2.11 already. So, that means if I want to fix a bug for one of my non-moved projects, I need to patch the 2.7, 2.8, 2.9, 2.10 and 2.11 branches, as well as the trunk. Anyone else think that's completely insane?!
For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign.
I think this is a dead horse now. Some things were deprecated without actually converting all instances where the deprecated code was in use. It's in your power to do something about it, go ahead.
Yeah, I have been, but I've hit exactly the problem described above. I fixed one chunk of zLOG warning on 2.9, and found they'd been fixed by someone else on the trunk in a different fashion. Pretty annoying :-( Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Andreas Jung wrote:
For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign.
Deprecation warning is only annoying but not a bad sign. Deprecations are not a functional problem.
That sends a pretty bad message. It's not really acceptable for a stable (ie: non-beta) point release to emit deprecation warnings. It's a sign that time-based releases are forcing releases that aren't ready to become "production releases" :-(
right...I did not think that we deprecated and removed something without having a reasonable replacement...or did we?
I think the timeframes feel to short. If we really must have time based releases (and I'm really starting to feel like they're a bad idea...) then 9 months or a year would be better between new feature releases. Personally, I find non-time-based releases a much nicer prospect: you only need to move to the next major version when it's ready and because it contains big new features you really want. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote: [snip]
Personally, I find non-time-based releases a much nicer prospect: you only need to move to the next major version when it's ready and because it contains big new features you really want.
Who is going to develop these big features? What's the motivation? I'm not going to develop major features if I know it might be a year or more before I can actually get to use them. Regards, Martijn
Martijn Faassen wrote:
Chris Withers wrote: [snip]
Personally, I find non-time-based releases a much nicer prospect: you only need to move to the next major version when it's ready and because it contains big new features you really want.
Who is going to develop these big features? What's the motivation? I'm not going to develop major features if I know it might be a year or more before I can actually get to use them.
Maybe there's something to be said for the "stable/development" branch split that linux has, or something similar? Even numbered releases are "feature add" releases: 2.12.0 - "okay, lets start adding features" 2.12.1 - "whoops, fixed bug x" 2.12.2 - "added feature y" 2.12.3 - "whoops, fixed bug z" 2.12.0 - "added feature z" 2.14.1 - "whoops, fixed bug a" Odd numbered releases are "stable" releases: 2.13.0 - "we're happy that all features up to y are stable" 2.13.1 - "whoops, fixed bug z" 2.13.2 - "whoops, fixed bug a" Using this model, there's at most 2 actively maintained branches, which is the big win for me right now. For bug #2016, Tres had to patch 4 different ZODB branches and then re-point 4 different svn:externals. With what I propose above, the number would be at least halved in both cases. People like Martijn could track the even releases, get all the new features, etc. People like me (when I have my "stable projects" hat on) could track the odd releases and not worry about stuff breaking every few months. I'd see the move that created 2.13 above to be a "big deal", maybe once every year or two, but one where there should be a well-tested and documented migration path from the last stable release. I dunno, I'm not saying the above is spot on, but maybe something we should think about? cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
--On 16. Juni 2006 09:12:36 +0100 Chris Withers <chris@simplistix.co.uk> wrote:
Even numbered releases are "feature add" releases: 2.12.0 - "okay, lets start adding features" 2.12.1 - "whoops, fixed bug x" 2.12.2 - "added feature y" 2.12.3 - "whoops, fixed bug z" 2.12.0 - "added feature z" 2.14.1 - "whoops, fixed bug a"
Odd numbered releases are "stable" releases: 2.13.0 - "we're happy that all features up to y are stable" 2.13.1 - "whoops, fixed bug z" 2.13.2 - "whoops, fixed bug a"
-10 I don't know what that model should solve? We must distinguish between the deprecation period for feature and the maintenance period of release. Both a currently one year. I have no problem with supporting releases for longer than one yr. In practice it is no big effort to apply patches too older branches as well (e.g. to keep 2.8 longer alive)...I think we *should* support older branches for longer than one yr since Zope 2 is used in large installatioins and ppl expect a certain amount of maintenance over a period of time. I see little reason not to fulfill this requirement..making a bugfix release from time to time is not really the problem. As an example a lot of Plone 2.1 site run on Zope 2.8 and we should support Zope 2.8 in a reasonable way as long as necessary (basically until Plone 2.5 on Zope 2.9 is adopted by most sites). U My recommendation: 1 yr deprecation period as it is now 1 yr + X maintenance period for older branches. Andreas -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 16 Jun 2006, at 10:28, Andreas Jung wrote:
My recommendation:
1 yr deprecation period as it is now 1 yr + X maintenance period for older branches.
+1 jens -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEkm+bRAx5nvEhZLIRAuLsAKCFJUV8mxeuCLVe92J30Ui5MVbXxgCgivJX aqeRzGUkriLqh663oIbiwNo= =K9tT -----END PGP SIGNATURE-----
Jens Vagelpohl wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 16 Jun 2006, at 10:28, Andreas Jung wrote:
My recommendation:
1 yr deprecation period as it is now 1 yr + X maintenance period for older branches.
+1
Extending the maintenance period for older branches indeed sounds like a good idea. Regards, Martijn
Martijn Faassen wrote:
+1
Extending the maintenance period for older branches indeed sounds like a good idea.
Hang on, that makes things even worse for the already-stressed developers though. The branches there are combined with the longer they're stable for gives you the "developer stress". cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Martijn Faassen wrote:
+1
Extending the maintenance period for older branches indeed sounds like a good idea.
Hang on, that makes things even worse for the already-stressed developers though. The branches there are combined with the longer they're stable for gives you the "developer stress".
Yes. This is all dependent on the assumption that there are developers interested in maintaining the older versions. If these developers do not exist, we have a problem. It's clear that the picked up speed of development of Zope 2 is stressful for developers at some point. No development of Zope 2 is bad for the platform, and thus stressful for developers on the longer run who will either have to learn something new, or have to maintain a "frozen" Zope 2 all by themselves. I think we've concluded a number of things: * some developers (Andreas in particular) do not consider it a huge problem to keep maintaining an older version for some time longer, if the fixes are relatively simple to apply. * we really want to be a bit more careful with deprecating things. We don't want to deprecate code in the transition from 2.8.4 to 2.8.5, for instance, only with feature releases. Perhaps these two points already help us go into the right direction. The Five model of establishing new code in parallel to the existing Zope 2 code was pretty succesful in not breaking stuff. Perhaps we should see whether we can apply this more often. On the other hand, the Five model of not changing the core also has serious limitations. Some things Five is doing now are really dependent on some core changes, and would be very hard to accomplish without them. In addition, we're also interested in making larger bits of Zope 2 work with Zope 3 code so we can stop maintaining two code bases. This inevitably causes pain. I think the pain is necessary. The pain should be kept under control: * predictable pain. Predictable releases. Predictable deprecation policy. Good communication of direction. I think we've been reasonable at this. * make it clear that pain leads to gains. We should communicate what we *win* by making a change. Sometimes a change only is good for the Zope maintainers, but often there are also potential neat things for Zope 2 developers. We should let them know. I think we've had some good advocates for this, but perhaps we should have a clear location on the zope website :) for this. * make it clear how to make the pain go away. We should have better documentation describing what a developer should do during an upgrade to a new Zope version. I think we can do a lot better at this. * optional buy-in pain. Follow the Five model where new code is developed in parallel to the existing codebase, and you can opt into it or stick with the old system. Sometimes this isn't possible. At other times it's mostly a delaying action, but that might be useful nonetheless. I think we've balanced this reasonably, but unfortunately things like this are just not possible forever, as there's a maintenance cost. * soften the pain. If we can afford it, a longer maintenance period for the Zope 2 platform might be nice. Andreas is sounding very friendly about this, so that's cool. :) Regards, Martijn
As always, Martijn has prettymuch hit the nail on the head with this mail, +lots to all the points he raises... Chris Martijn Faassen wrote:
I think we've concluded a number of things:
* some developers (Andreas in particular) do not consider it a huge problem to keep maintaining an older version for some time longer, if the fixes are relatively simple to apply.
* we really want to be a bit more careful with deprecating things. We don't want to deprecate code in the transition from 2.8.4 to 2.8.5, for instance, only with feature releases.
Perhaps these two points already help us go into the right direction.
The Five model of establishing new code in parallel to the existing Zope 2 code was pretty succesful in not breaking stuff. Perhaps we should see whether we can apply this more often.
On the other hand, the Five model of not changing the core also has serious limitations. Some things Five is doing now are really dependent on some core changes, and would be very hard to accomplish without them. In addition, we're also interested in making larger bits of Zope 2 work with Zope 3 code so we can stop maintaining two code bases. This inevitably causes pain. I think the pain is necessary.
The pain should be kept under control:
* predictable pain. Predictable releases. Predictable deprecation policy. Good communication of direction. I think we've been reasonable at this.
* make it clear that pain leads to gains. We should communicate what we *win* by making a change. Sometimes a change only is good for the Zope maintainers, but often there are also potential neat things for Zope 2 developers. We should let them know. I think we've had some good advocates for this, but perhaps we should have a clear location on the zope website :) for this.
* make it clear how to make the pain go away. We should have better documentation describing what a developer should do during an upgrade to a new Zope version. I think we can do a lot better at this.
* optional buy-in pain. Follow the Five model where new code is developed in parallel to the existing codebase, and you can opt into it or stick with the old system. Sometimes this isn't possible. At other times it's mostly a delaying action, but that might be useful nonetheless. I think we've balanced this reasonably, but unfortunately things like this are just not possible forever, as there's a maintenance cost.
* soften the pain. If we can afford it, a longer maintenance period for the Zope 2 platform might be nice. Andreas is sounding very friendly about this, so that's cool. :)
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Andreas Jung wrote:
My recommendation:
1 yr deprecation period as it is now 1 yr + X maintenance period for older branches.
+1 Note that this should also extend to the Zope 3 releases. Zope 3.2 is part of Zope 2.9 and will hence be used for quite some time. Yet, bugfixes aren't even backported to the Zope 3.2 branch anymore... Philipp
Philipp von Weitershausen wrote:
Andreas Jung wrote:
My recommendation:
1 yr deprecation period as it is now 1 yr + X maintenance period for older branches.
+1
Note that this should also extend to the Zope 3 releases. Zope 3.2 is part of Zope 2.9 and will hence be used for quite some time. Yet, bugfixes aren't even backported to the Zope 3.2 branch anymore...
Is there any chance we can create an overview page that reflects the status of what changes need to be ported where and what the status of that branch is? Maybe some kind of matrixy-thingy? However, I'm afraid any page in the development area will get lost in that sea of pages ... :) Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
On Sun, Jun 18, 2006 at 02:29:14PM -0400, Christian Theune wrote:
Philipp von Weitershausen wrote:
Andreas Jung wrote:
My recommendation:
1 yr deprecation period as it is now 1 yr + X maintenance period for older branches.
+1
Note that this should also extend to the Zope 3 releases. Zope 3.2 is part of Zope 2.9 and will hence be used for quite some time. Yet, bugfixes aren't even backported to the Zope 3.2 branch anymore...
Is there any chance we can create an overview page that reflects the status of what changes need to be ported where and what the status of that branch is? Maybe some kind of matrixy-thingy?
+1, I'd like some way to easily know when a release is no longer maintained. i.e., what's the X in the above formula. as others have observed, bugfixing is easier when you have fewer branches to patch and test... -- Paul Winkler http://www.slinkp.com
On 6/18/06, Paul Winkler <pw_lists@slinkp.com> wrote:
+1, I'd like some way to easily know when a release is no longer maintained. i.e., what's the X in the above formula.
Well, it's 2 versions, so far. I.e, current release and last release. Unless we decide to change that now. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On Sun, Jun 18, 2006 at 08:30:58PM +0200, Lennart Regebro wrote:
On 6/18/06, Paul Winkler <pw_lists@slinkp.com> wrote:
+1, I'd like some way to easily know when a release is no longer maintained. i.e., what's the X in the above formula.
Well, it's 2 versions, so far. I.e, current release and last release. Unless we decide to change that now.
OK, but just to clarify: Will we stop having to backport bugfixes to 2.8 when 2.10 final is released? But we need to backport bugfixes during the 2.10 beta cycle? Is this policy written down somewhere? -- Paul Winkler http://www.slinkp.com
--On 18. Juni 2006 14:35:48 -0400 Paul Winkler <pw_lists@slinkp.com> wrote:
On Sun, Jun 18, 2006 at 08:30:58PM +0200, Lennart Regebro wrote:
On 6/18/06, Paul Winkler <pw_lists@slinkp.com> wrote:
+1, I'd like some way to easily know when a release is no longer maintained. i.e., what's the X in the above formula.
Well, it's 2 versions, so far. I.e, current release and last release. Unless we decide to change that now.
OK, but just to clarify: Will we stop having to backport bugfixes to 2.8 when 2.10 final is released? But we need to backport bugfixes during the 2.10 beta cycle?
My personal rule: if a fix/patch applies without a major effort to Zope 2.8 than I will apply it (major effort means for me: some minutes). If a fix is important (whatever this means) I might invest some more time...but only speaking for myself. In edge cases we should decide from case to case. Andreas
Lennart Regebro wrote:
On 6/18/06, Paul Winkler <pw_lists@slinkp.com> wrote:
+1, I'd like some way to easily know when a release is no longer maintained. i.e., what's the X in the above formula.
Well, it's 2 versions, so far. I.e, current release and last release. Unless we decide to change that now.
Right now we have: Zope 2.9 Zope 2.10 pre-stable Zope 2 trunk Zope 3.2 Zope 3.3 pre-stable Zope 3 trunk AFAICT The pre-stable versions should usually only be around in May/June and December/January. However, Zope 2.8 is still available for stable download ... so we currently have 7 branches to watch out for. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
--On 18. Juni 2006 14:36:06 -0400 Christian Theune <ct@gocept.com> wrote:
However, Zope 2.8 is still available for stable download ... so we currently have 7 branches to watch out for.
Yes, but in most cases a fix only affects only Zope 2 or Zope 3. So we are back to 3. -aj -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 E-Publishing, Python, Zope & Plone development, Consulting
Andreas Jung wrote:
--On 18. Juni 2006 14:36:06 -0400 Christian Theune <ct@gocept.com> wrote:
However, Zope 2.8 is still available for stable download ... so we currently have 7 branches to watch out for.
Yes, but in most cases a fix only affects only Zope 2 or Zope 3. So we are back to 3.
Right. 3 for each. And you do have to *think* whether a fix affects the other one or not. That's the hard part, isn't it? -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - ct@gocept.com - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
--On 18. Juni 2006 14:46:27 -0400 Christian Theune <ct@gocept.com> wrote:
Andreas Jung wrote:
--On 18. Juni 2006 14:36:06 -0400 Christian Theune <ct@gocept.com> wrote:
However, Zope 2.8 is still available for stable download ... so we currently have 7 branches to watch out for.
Yes, but in most cases a fix only affects only Zope 2 or Zope 3. So we are back to 3.
Right. 3 for each. And you do have to *think* whether a fix affects the other one or not. That's the hard part, isn't it?
Of course we have to *think* but I think most cases are clear. Otherwise this belongs to the 0.12234724527% of the cases where you might break something...an element of risk remains.... -aj
Christian Theune wrote:
However, Zope 2.8 is still available for stable download ... so we currently have 7 branches to watch out for.
...and you're not even including ZODB branches and the like that need to be maintained and kept in sync... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Lennart Regebro wrote:
On 6/18/06, Paul Winkler <pw_lists@slinkp.com> wrote:
+1, I'd like some way to easily know when a release is no longer maintained. i.e., what's the X in the above formula.
Well, it's 2 versions, so far. I.e, current release and last release. Unless we decide to change that now.
Is it really? I'd suggest there are lots of people still on 2.7.x. When 2.10.x is released imminently, are you saying that everyone will suddenly jump off 2.8.x? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 6/19/06, Chris Withers <chris@simplistix.co.uk> wrote:
Well, it's 2 versions, so far. I.e, current release and last release. Unless we decide to change that now.
Is it really?
That's how it has been so far, yes. Maybe we should extend it. But mind you, that's more work... I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10. If somebody else is, fine. Supporting old versions mus reasonably be a
I'd suggest there are lots of people still on 2.7.x. When 2.10.x is released imminently, are you saying that everyone will suddenly jump off 2.8.x?
Chris
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
On 6/19/06, Lennart Regebro <regebro@gmail.com> wrote:
I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10. If somebody else is, fine. Supporting old versions mus reasonably be a
Let me continue that. :) Supporting old versions must reasonably be a community effort, depending on if people have the time to do so. We can't just say "three versions should be officially supported" and then not doing it. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Lennart Regebro wrote:
Supporting old versions must reasonably be a community effort, depending on if people have the time to do so. We can't just say "three versions should be officially supported" and then not doing it.
Yup, and I think it's safe to say the fewer version we need to support, the more likely it is to happen. I think it's also safe to say that some people will stick with a "good vintage" zope which has all the features they need and was stable. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 6/20/06, Chris Withers <chris@simplistix.co.uk> wrote:
I think it's also safe to say that some people will stick with a "good vintage" zope which has all the features they need and was stable.
And that's OK, and in many cases completely sensible. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
--On 19. Juni 2006 16:25:32 +0200 Lennart Regebro <regebro@gmail.com> wrote:
I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10.
We don't talk about Zope 2.7 which is dead. -aj
Andreas Jung wrote:
I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10.
We don't talk about Zope 2.7 which is dead.
...except for all the people still using it ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Andreas Jung wrote:
I for one, is NOT interested in backporting fixed in Five trunk to both Five 1.0, 1.1, 1.3, 1.4 and 1.5, which is what are the current versions of Five if we say that Zope 2.8 and 2.7 should be still supported after the release of 2.10.
We don't talk about Zope 2.7 which is dead.
...except for all the people still using it ;-)
It's dead from a maintenance point of view. If you still want to maintain it, be our guest. But you yourself said that maintaining too many branches is madness. There's nothing wrong with software being in production whose particular line isn't maintained anymore. I have Linux kernels 2.4 and Apaches 1.3 in production. What's your point? Philipp
On 6/21/06, Philipp von Weitershausen <philipp@weitershausen.de> wrote:
There's nothing wrong with software being in production whose particular line isn't maintained anymore. I have Linux kernels 2.4 and Apaches 1.3 in production. What's your point?
I checked what all my websites run. They are all on Zope 2.5. No problemas. :) -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
Philipp von Weitershausen wrote:
It's dead from a maintenance point of view. If you still want to maintain it, be our guest. But you yourself said that maintaining too many branches is madness.
My point is that we're creating too many branches ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
--On 26. Juni 2006 11:25:05 +0100 Chris Withers <chris@simplistix.co.uk> wrote:
Philipp von Weitershausen wrote:
It's dead from a maintenance point of view. If you still want to maintain it, be our guest. But you yourself said that maintaining too many branches is madness.
My point is that we're creating too many branches ;-)
Bascially 3 at this time. As I pointed out earlier it does not take too much effort e.g. to apply fixes to the 2.8 branch *as needed*. Andreas
Philipp von Weitershausen wrote:
Note that this should also extend to the Zope 3 releases. Zope 3.2 is part of Zope 2.9 and will hence be used for quite some time. Yet, bugfixes aren't even backported to the Zope 3.2 branch anymore...
It's this sort of thing that makes me wish we could unify the source trees... Yes, it might make for a bigger tarball for "Zope 3 only" folk, but it'd make the release/dependency/etc cycle easier for the larger majority... cheers, Chris - who remembers when Zope 3 was still a CVS branch of Zope 2 ;-) -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Philipp von Weitershausen wrote:
Note that this should also extend to the Zope 3 releases. Zope 3.2 is part of Zope 2.9 and will hence be used for quite some time. Yet, bugfixes aren't even backported to the Zope 3.2 branch anymore...
It's this sort of thing that makes me wish we could unify the source trees...
You know, I had a proposal once... Uh, never mind. Philipp
Benji York wrote:
Philipp von Weitershausen wrote:
Uh, never mind.
+1 :)
Any chance you could explain why you feel that way? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Benji York wrote:
Philipp von Weitershausen wrote:
Uh, never mind.
+1 :)
Any chance you could explain why you feel that way?
Follow this thread: http://mail.zope.org/pipermail/zope3-dev/2005-November/016561.html Philipp
Philipp von Weitershausen wrote:
Follow this thread: http://mail.zope.org/pipermail/zope3-dev/2005-November/016561.html
*grunt* *sigh* It has to happen at some stage, surely? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote:
Philipp von Weitershausen wrote:
Follow this thread: http://mail.zope.org/pipermail/zope3-dev/2005-November/016561.html
*grunt* *sigh*
It has to happen at some stage, surely?
Jim suggested a different strategy with "Zope 5" (http://mail.zope.org/pipermail/zope3-dev/2006-February/018415.html). The little bits and pieces that make up Zope 3 (the zope.* packages) would be developed more or less independently of Zope-the-app-server (which would only be one product called Zope 5 and incorporate ideas from Zope 2 and 3 and use those bits and pieces). Philipp
Philipp von Weitershausen wrote:
Jim suggested a different strategy with "Zope 5" (http://mail.zope.org/pipermail/zope3-dev/2006-February/018415.html). The little bits and pieces that make up Zope 3 (the zope.* packages) would be developed more or less independently of Zope-the-app-server (which would only be one product called Zope 5 and incorporate ideas from Zope 2 and 3 and use those bits and pieces).
Well, the sooner better... ...this comes mainly from my desire to see the "exponential combination of branches" problem go away... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
A small question/idea. When making svn:externals in Nuxeo, we always use https. That way trees can still be checked out anonymously, but still modified. in Zope, threes are checked out with svn+ssh, but externals use svn. That means that when you want to modify for example Five, you need to delete the svn checkout and do an svn+ssh checkout instead. Also, if you start changing things without remembering that you have to make a fresh checkout, you have to svn diff it and them manually merge it into the fresh checkout, and if you later do an "svn up", your changes will be moved into a dead *.OLD directory (where you can't do svn diff to extract your changes) and so on. The benefit of that is that you don't by mistake check in on a tag... My question is: Is there a good way of not having to check out a fresh copy before you do changes? If not how would people feel about switching to https or something instead? Especially if we merge the trees, in which case both Zope2 and Zope3 will be made up mainly of svn:externals... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:
A small question/idea.
When making svn:externals in Nuxeo, we always use https. That way trees can still be checked out anonymously, but still modified.
in Zope, threes are checked out with svn+ssh, but externals use svn. That means that when you want to modify for example Five, you need to delete the svn checkout and do an svn+ssh checkout instead. Also, if you start changing things without remembering that you have to make a fresh checkout, you have to svn diff it and them manually merge it into the fresh checkout, and if you later do an "svn up", your changes will be moved into a dead *.OLD directory (where you can't do svn diff to extract your changes) and so on.
The benefit of that is that you don't by mistake check in on a tag...
My question is: Is there a good way of not having to check out a fresh copy before you do changes? If not how would people feel about switching to https or something instead? Especially if we merge the trees, in which case both Zope2 and Zope3 will be made up mainly of svn:externals...
- -1. The externals are just that, external to the Zope project. Modifying them should require extra thought, and a little extra effort, because the possibility exists that the change might break something outside the Zope tree. When we get to an egg-based Zope install, I think such a gesture would map onto "check out the source egg and force it into the path.' Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoB5L+gerLs4ltQ4RAqfRAKDUrcW7NYg4ljtHvYZto3H5hARV1gCglHWv 2pqpEsGwE1h6rckFpJgcmTo= =/cbq -----END PGP SIGNATURE-----
On 6/26/06, Tres Seaver <tseaver@palladion.com> wrote:
- -1. The externals are just that, external to the Zope project.
Uhm. I have a hard time seeing Five and lib/python/zope as "external to Zope".
When we get to an egg-based Zope install, I think such a gesture would map onto "check out the source egg and force it into the path.'
Yeah, with eggs this issue might go away... -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lennart Regebro wrote:
On 6/26/06, Tres Seaver <tseaver@palladion.com> wrote:
- -1. The externals are just that, external to the Zope project.
Uhm. I have a hard time seeing Five and lib/python/zope as "external to Zope".
They are managed as separate projects, with their own priorities and releases. ZODB is the longest-running example of this "externality."
When we get to an egg-based Zope install, I think such a gesture would map onto "check out the source egg and force it into the path.'
Yeah, with eggs this issue might go away...
Right. The 'svn:externals' will morph into dependencies, which will still be managed exterally to the dependent package. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFEoCer+gerLs4ltQ4RAqnwAKCVr5TeOU0XyLG/6drpaTJ65lGgiwCfbD74 V6ArZP8baL0Vo2fafxJQYOg= =fcxE -----END PGP SIGNATURE-----
Chris Withers wrote:
Philipp von Weitershausen wrote:
Jim suggested a different strategy with "Zope 5" (http://mail.zope.org/pipermail/zope3-dev/2006-February/018415.html). The little bits and pieces that make up Zope 3 (the zope.* packages) would be developed more or less independently of Zope-the-app-server (which would only be one product called Zope 5 and incorporate ideas from Zope 2 and 3 and use those bits and pieces).
Well, the sooner better...
...this comes mainly from my desire to see the "exponential combination of branches" problem go away...
Technically speaking, isn't that a squared problem? -- 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
Max M wrote:
Well, the sooner better...
...this comes mainly from my desire to see the "exponential combination of branches" problem go away...
Technically speaking, isn't that a squared problem?
That depends how many pieces of software are involved ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
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. -- Dieter
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
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
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
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 R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
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
Hi Chris! Chris McDonough wrote:
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.
This sounds like a good compromise. At least for 'methods'. I don't know if we should leave it there forever, but we could keep it at least until it gets in the way of code improvements. Nobody complained about removing '__ac_permissions__' and 'meta_types' support, so I guess they can be removed in Zope 2.11. Cheers, Yuppie
On Jun 15, 2006, at 11:42 AM, yuppie wrote:
Hi Chris!
Chris McDonough wrote:
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.
This sounds like a good compromise. At least for 'methods'. I don't know if we should leave it there forever, but we could keep it at least until it gets in the way of code improvements.
+1
Nobody complained about removing '__ac_permissions__' and 'meta_types' support, so I guess they can be removed in Zope 2.11.
+1 - C
Philipp von Weitershausen wrote at 2006-6-15 09:13 +0200:
... 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:
Indeed.
* 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. I understand the wish to have only a single ZPT implementation.
... 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... -- Dieter
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
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
Florent Guillaume wrote at 2006-6-13 22:13 +0200:
... Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss.
Interestingly, it is usually not the loss for the third party product developers (as they usually gain nothing from their products) -- but for the people using the product. Personally, I will simply blame Zope when one of my products breaks for some stupid BBB incompatibility (such as removing "zLOG" or "methods" support in initialization modules) introduced by some Zope release. I will fix them only, when I myself upgrade to a newer Zope and hit the problems (only then, I can reproduce the problem and check that the fix really fixes). I am slowly upgrading (still using Zope 2.8). Unlike Nuxeo, I do not get money (or other rewards) for keeping my products in sync with the current Zope releases. -- Dieter
On 14 Jun 2006, at 22:06, Dieter Maurer wrote:
Florent Guillaume wrote at 2006-6-13 22:13 +0200:
Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss.
Interestingly, it is usually not the loss for the third party product developers (as they usually gain nothing from their products) -- but for the people using the product.
When users repeatedly bitch to the developer because a product doesn't work with a newer Zope version, it's a loss of time for the developer. He would have gained time by doing the correction in advance of the users discovering the problem.
Personally, I will simply blame Zope when one of my products breaks for some stupid BBB incompatibility (such as removing "zLOG" or "methods" support in initialization modules) introduced by some Zope release.
I will fix them only, when I myself upgrade to a newer Zope and hit the problems (only then, I can reproduce the problem and check that the fix really fixes). I am slowly upgrading (still using Zope 2.8). Unlike Nuxeo, I do not get money (or other rewards) for keeping my products in sync with the current Zope releases.
Nuxeo isn't getting money from using Zope 2.10, for instance, it's just that we believe that any improvements is worth putting back into Zope itself (if only so that maintenance is shared and peer-reviewed) and not kept in our own tree. Being interested in improving the framework means that we have to work with it, and it's better to work with something clean than with something that has accumulated years and years of cruft. So we're interested in cleaning up the framework. This means deprecating broken, old or dirty stuff at some point. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com fg@nuxeo.com
Florent Guillaume wrote at 2006-6-14 22:48 +0200:
On 14 Jun 2006, at 22:06, Dieter Maurer wrote:
Florent Guillaume wrote at 2006-6-13 22:13 +0200:
Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss.
Interestingly, it is usually not the loss for the third party product developers (as they usually gain nothing from their products) -- but for the people using the product.
When users repeatedly bitch to the developer because a product doesn't work with a newer Zope version, it's a loss of time for the developer. He would have gained time by doing the correction in advance of the users discovering the problem.
I will send back a standard response saying: blame Zope for removing "cosmetic annoyances" and thereby breaking third party products.
... Being interested in improving the framework means that we have to work with it, and it's better to work with something clean than with something that has accumulated years and years of cruft.
Are you sure that removing about a dozen lines for the tiny "zLOG" wrapper or about as many lines for the "methods" feature really contributes much to cleaning up years of cruft? On the other hand, it forces much bigger changes in third party (and Zope) code -- Dieter
participants (18)
-
Andreas Jung -
Benji York -
Chris McDonough -
Chris Withers -
Christian Theune -
Dieter Maurer -
Florent Guillaume -
Jens Vagelpohl -
Lennart Regebro -
Martijn Faassen -
Max M -
Paul Winkler -
Philipp von Weitershausen -
Rob Miller -
Rocky Burt -
Tres Seaver -
Wichert Akkerman -
yuppie