On Wed, 2006-06-14 at 13:34 +0200, Lennart Regebro wrote: > On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> 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 _______________________________________________ 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 )