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

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

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 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

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 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

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

-----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-----

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

-----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-----

-----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-----

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

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

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 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 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/

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

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 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

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

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

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

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 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 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 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

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

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

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

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

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

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

-----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-----

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

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

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/

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-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

-----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:

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

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

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

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

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

--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

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

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

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

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 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

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

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

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

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/

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 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

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

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

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

Philipp von Weitershausen wrote:

Uh, never mind.

+1 :) -- Benji York Senior Software Engineer Zope Corporation

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

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

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/

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/

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

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

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

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

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

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

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

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