Re: [Zope-dev] Time-based releases a good idea?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
Andreas Jung wrote: Right. As a rule we must fix any code in the Zope core that would possibly spit out a deprecation warning caused by a deprecation warning. At least for zLOG in Zope 2.9 we (possibly only me) were not totally consequent. Yes, I noticed your name in "svn praise" ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
Andreas Jung wrote: For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign. Deprecation warning is only annoying but not a bad sign. Deprecations are not a functional problem. That sends a pretty bad message. It's not really acceptable for a stable (ie: non-beta) point release to emit deprecation warnings. It's a sign that time-based releases are forcing releases that aren't ready to become "production releases" :-( right...I did not think that we deprecated and removed something without having a reasonable replacement...or did we? I think the timeframes feel to short. If we really must have time based releases (and I'm really starting to feel like they're a bad idea...) then 9 months or a year would be better between new feature releases. Personally, I find non-time-based releases a much nicer prospect: you only need to move to the next major version when it's ready and because it contains big new features you really want. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
--On 14. Juni 2006 08:23:53 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote: The product I speak of above has 700 individual unit tests and still has bugs. Shrug. I expect some breakage, and the tests will catch most of them, and that's fine. But I also have maybe five or six open source products that I maintain which don't see attention every week or even every month or sometimes every six months, because I'm working on other stuff. These are problematic for me to keep in sync, which causes problems for other folks. You will always have this migration risk. The risk increases with the number of frameworks you use. This also happened lately with my current Plone project where the CUstomiziationPolicy API disappeared without deprecation in Plone 2.5 which is currently a blocker to upgrade from 2.1 to 2.5. -aj pgpdUpBJo1tHi.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
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! **
Re: [Zope-dev] Time-based releases a good idea?
On 6/14/06, Chris McDonough <[EMAIL PROTECTED]> wrote: The time-based release cycle just amplifies this across many branches and point releases, so nobody really knows which products work with what branch/release and under what configuration some feature is supposed to emit a deprecation warning without a good deal of testing. The *reason* I'm stuck back on 2.8 and haven't upgraded the products I maintain to behave nicely on 2.9+ is because I just can't keep the fuck up with these sorts of changes. It's a self- perpetuating cycle because the only sane defensive maneuver for me is to stick with 2.8 for existing customer projects. I say to myself that I'll move them to 2.9 or 2.10, or 2.11, or whatever happens to be the current release once I get a chance to breathe, but honestly, this is the *last* thing I'll do; I've got plenty of other coding to do. Well, ignoring the confusion about zLOG, updating things for a new version of Zope with deprecation warnings is not much work. Honestly. You update to the new version, look at the depracation warnings, and do search/replace until they go away. Unless their are compatibility bugs, and that will happen sometimes, that's it. I don't remember exactly how long it took to go to 2.9 for CPS, but it wasn't very much work, and it was all related to changes in Five, which you don't seem to use or worry about. 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/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
--On 14. Juni 2006 06:47:37 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Warning: This is gonna be ranty and will almost certainly contain foul language. ;-) You're allowed to do so :-) There was a message sent to the list about deprecating zLOG on January 8 of this year by Andreas, but it was supposed to have been deprecated in 2.10, not any 2.9 release, and was supposed to have gone away in 2.12, not in 2.11, as the currently 2.9 deprecation warnings for zLOG state. And why the should the core emit a deprecation warning? If the core uses it, it by definition shouldn't (*can't*) be deprecated. What's the goal here? Removing zLOG is (at least by any sane measure) totally gratuitous in the first place, we have conflicting reports about which version it's going to be deprecated in, and it's not even actually deprecated! This is the definition of a clusterfuck. Some comments in the zLOG module stated that it was intended to deprecate zLOG in Zope 2.8 afaik (not checking the sources right now). So I deprecated it in Zope 2.9 (without migrating all occurrences (mea culpa)...a cosmetic problem in my opinion) and it is now removed for Zope 2.11.. Yes, I know. I should have spoken up earlier about zLOG. But to be honest I'm just barely keeping my head above water as it is, so I'm hoping to be able to trust that people make wise decisions about this sort of thing, and my main defense mechanism at this point is limited to covering my eyes and hoping everything will turn out ok. I'm hoping that people won't removing some random API for the sake of a hard-on over a Platonic ideal. Is that unreasonable? At least on the module level we did not remove something without a proper replacement. So, anyway, I have a really significant number of released products that make use of zLOG. I can't keep up with the release cycle, or the deprecations. These products will likely just be broken for new Zope releases and will emit warning messages for stable branches for some period of time. People are gonna be pissed. But there's not much I can do about it short of just giving up maintainership of those products to someone who is able and willing to keep up. There's only like, what, maybe 20 people who have demonstrated willingness to maintain the *core*, so it's a pretty fat chance of me finding one of those people to maintain my stuff. At some point you have to make a cut to get rid of old crap. Fixing the zLOG issue is a straight forward approach with very little risks for the programmer and it won't take too much time..I don't see a major problem with that. There *have* to be other people in the same boat as I am. Speak up if so! Zope 2 is really just not the place to make sweeping innovations. We are losing working products as a result of these "innovations", and as a result, probably developers, and as a result of that, end users. In general we are being *way*, *way*, *way* too aggressive about deprecations and API changes in Zope 2. Sometimes you just need to live with your mistakes. I'd hope that people will try to be conservative in the future. I agree almost with everything of that. However being conservative should not avoid making progress. This still raises the question: where shall be go with Zope 2. My theory is that Zope 3 will be the spare-part factory for Zope2 (please no beatings from the Zope 3 world :-)) and that Zope 2 will have a long life. This implies that we need to adopt more and more Z3 technology. Such integration will raise deprecation issue and possible...and it is our goal to minimize these issues. ...but that's only my personal theory. Andreas pgpSJ3RHCrZVv.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
-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 <[EMAIL PROTECTED]> 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/listinf
Re: [Zope-dev] Time-based releases a good idea?
--On 14. Juni 2006 10:28:08 +0200 Jens Vagelpohl <[EMAIL PROTECTED]> 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 pgprTUTFQzyDu.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
-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 <[EMAIL PROTECTED]> 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- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Time-based releases a good idea?
--On 14. Juni 2006 07:32:42 +0100 Chris Withers <[EMAIL PROTECTED]> wrote: Florent Guillaume wrote: Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. And this is only for Zope 2.10 which I doubt these third party products are using at the moment. If we don't remove things at some point, there's no point in doing deprecation warnings. This and things like it have been niggling me for a while now and I guess this finally prompted me to write a mail on it... I know the good reasoning behind the time-based releases, but have they really worked out? Yes and No. Yes: It's a must to have Zope 2 and Zope 3 in sync. Zope 2 development got a some more momentum again.. No: Half a yr is a short time. Major changes happened right short before the first beta release. Not all Zope users won't follow this fast release cycle. For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign. Deprecation warning is only annoying but not a bad sign. Deprecations are not a functional problem. Now, this could all be seen as fair game, Zope _is_ going through a period of big and positive change as Zope 2 and Zope 3 converge, things like zLOG finally get put to rest and we move onto newer more powerful versions of python. right...I did not think that we deprecated and removed something without having a reasonable replacement...or did we? If that's the case, then I hope we, as a community, "get there" at some point and can get back to focusing on the stability of the good ol' days. +1, +1, +1 Andreas PS @all developers: I hope you don't forget the bugday tomorrow :-)) pgpcyrA2gyahB.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Time-based releases a good idea?
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 ___ 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 )
