Re: [Zope-dev] Re: Time-based releases a good idea?
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-6-18 12:38 +0200: ... deprecation policy ... This policy allows us to move forward (which Zope 2 never really did for the the majority of those five years you mention). Although, it might help in a few cases, it is not at all necessary to cast ones history away when moving forward. I do not agree with you that Zope2 did not move forward in the past 5 years. I agree that currently it moves faster -- but not because you cast out things but because you move lots of new functionality in. +lots Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
Philipp von Weitershausen wrote at 2006-6-18 12:38 +0200: ... deprecation policy ... This policy allows us to move forward (which Zope 2 never really did for the the majority of those five years you mention). Although, it might help in a few cases, it is not at all necessary to cast ones history away when moving forward. I do not agree with you that Zope2 did not move forward in the past 5 years. I agree that currently it moves faster -- but not because you cast out things but because you move lots of new functionality in. -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
Tres Seaver wrote: Unit test coverate for custom products is actually quite good. The problems are nearly always to do with third party products, many of which have been in useful stable mode since long before either deprectaions or ubiquitous unit testing were part of our community's development culture. Case in point: Squishdot hasn't seen any active maintenance in about 5 years, but it still worked fine up until zLOG disappeared and I started getting whine about 'methods'... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
Lennart Regebro wrote: So this is not a problem with deprecation period, time based releases or anything else, then. No, but the slew of deprecation warnings, proliferation of branches that need to be supported (regardless of whether they're officially production or not) and sheer amount of change you now HAVE (rather than 'can choose') to deal with seems a sign, at least to me, that time-based releases were a nice experiment, but maybe it's time to think again? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
Chris Withers wrote: Lennart Regebro wrote: So this is not a problem with deprecation period, time based releases or anything else, then. No, but the slew of deprecation warnings, proliferation of branches that need to be supported (regardless of whether they're officially production or not) and sheer amount of change you now HAVE (rather than 'can choose') to deal with seems a sign, at least to me, that time-based releases were a nice experiment, but maybe it's time to think again? I disagree completely. I think time based releases were a factor in rescuing at least Zope 2 from complete stagnation. I also think that time based releases have helped getting a lot more Zope 3 to everybody much faster than before. They have encouraged people to actually contribute to the core, as they know the fix or feature will be in there in a few months, at a predictable time, not years in the indefinitey future as it was before. Overall I think time based releases have been overwhelmingly *successful*. And yes, porting applications to new releases takes time and is frequently painful. If the alternative is stagnation or having to write code against old APIs that I know have better alternatives somewhere in subversion but don't know when they'll ever get released, I'll gladly take that pain. That said, of course things have to be done carefully. Stick with the release policy we all should be following anyway: don't deprecate anything in a bugfix release. Carefully consider backwards compatibility. Back out of changes that are too damaging. I'm curious to hear what alternative you'd prefer. I didn't like the old release policy much: from 2.6 to 2.7 took over a year and a half. The alpha for 2.7 was released almost a *year* before 2.7 was finally released. It then took a year for 2.8 to be released. Nobody knew what was going to happen when, and Zope 2 development was pretty stagnant for huge spans of time (not discounting the wonderful work that *was* done in that period). People were building piles of framework code on top of Zope that should've gone into the core where we could all share it, but people avoided the core. Now, Zope 2 is alive again. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
Chris McDonough wrote at 2006-6-14 14:50 -0400: ... PsycoPG-DA does, MySQLDA does, one of my products named ZopeMailArchive does. CCSQLMethods does (because until very recently ZSQLMethods did, hopefully changed now). -- Dieter ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
On 6/14/06, Max M [EMAIL PROTECTED] wrote: But the problem is that I don't fix bugs that doesn't exist for my customers. So deprecation warnings are ignored, until the product sponsor chooses upgrade. Very reasonable. If this is how OSS generally works, as I expect, then deprecations will break stuff that just doesn't get fixed. I'm not sure I follow you here. Deprecations in themselves break nothing, of course, so I assume you mean that the changes break stuff that doesn't get updated. This is true, but that is true for any non-backwards-compatible change. And every single major Zope version have had some sort of non-backwards-compatible change. That is, in fact, the whole definition of the major version. Otherwise it would be a bugfix. :) And new user will find it impossible to get all the products they need to work together, in the latest version. This is true, and a problem. And the more modules you have the worse it gets, as you get big compatibility matrices going on. But there is only one answer to that, and that is to update the software. It doens't mean *you* have to do so. But somebody has, reasonably whoever needs the update. That's OSS. :) Things get REALLY complex if you try to keep several version bugfree at the same time, which I guess is one of the reasons Chris stays on 2.8 so far. He doesn't want to have two branches, one 2.8 and one 2.9 compatible, and keep them both bugfree. This is very reasonable, and the reason for the deprecation period. The deprecation period gives you, in effect, 18 months notice. After 18 months, in the worst case, the feature you used is not any longer in any supported version of Zope. I think that's very reasonable. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 14:09 +0200, Wichert Akkerman wrote: No matter what period we decide on it will always be too short for some and too long for others. With the current setup the deprecation period is a year, which seems like a decent middle ground. A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. Currently adding a deprecation in a release doesn't automatically equate to a year's grace period, because people seem to assume they can deprecate a feature in a very late point release of the current stable branch and deprecate it exactly two releases later. Which in a time-based cycle is always shorter than a year, because the point release of the stable branch happens concurrently with development of the next major release. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
Previously Chris McDonough wrote: A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. I haven't kept track of zLOG (I'm still new to this world) so I don't know if that went according to the normal schedule or not. Currently adding a deprecation in a release doesn't automatically equate to a year's grace period, because people seem to assume they can deprecate a feature in a very late point release of the current stable branch and deprecate it exactly two releases later. Which in a time-based cycle is always shorter than a year, because the point release of the stable branch happens concurrently with development of the next major release. If I understand this correctly the problem you are seeing is this that you develop against an unreleased Zope version, so worst case your deprecation period starts just before the first beta of release x when someone adds a deprecation and ends at the time trunk opens for development for release x+2 and the deprecated feature is removed, which can be 6 months. I don't think that's a very fair method of measuring deprecation time: for stable releases which almost everyone uses the deprecation time will have been the full year. Wichert. - -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 15:44 +0200, Wichert Akkerman wrote: Previously Chris McDonough wrote: A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. I haven't kept track of zLOG (I'm still new to this world) so I don't know if that went according to the normal schedule or not. Actually, it will (or at least pretty close), since we aren't removing it until 2.11 (I computed 6 months based on 2.10, sorry). If I understand this correctly the problem you are seeing is this that you develop against an unreleased Zope version, so worst case your deprecation period starts just before the first beta of release x when someone adds a deprecation and ends at the time trunk opens for development for release x+2 and the deprecated feature is removed, which can be 6 months. No, actually, that's not what I mean. I don't think that's a very fair method of measuring deprecation time: for stable releases which almost everyone uses the deprecation time will have been the full year. Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) vs. http://svn.zope.org/Zope/branches/Zope-2_8-branch/lib/python/OFS/Application.py?rev=39882r1=39762r2=39882 (fixup checkin made Nov. 4, 2005, the earliest checkin for these deprecations was Oct. 31 2005). I'm no math genius, but that sure seems like about 8 months to me end-to-end. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
--On 14. Juni 2006 10:40:05 -0400 Chris McDonough [EMAIL PROTECTED] wrote: Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) You know that the project wikis were always vapourware wikis (find it good or not)...lots of plans before the next release but only a small number of plans will make it into the final release. Likely the dates above were added before we changed to the June/December release cycle. -aj pgpOGKFkrurCx.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
So... you're saying that 2.10 isn't going to be released until December 2006, then? That would indeed make the deprecation period longer than 1 year, which seems to have been the intent. But wouldn't that make Zope's a yearly release cycle, given that the first beta of 2.9 was released *last* December? Now I'm really confused. On Wed, 2006-06-14 at 16:46 +0200, Andreas Jung wrote: --On 14. Juni 2006 10:40:05 -0400 Chris McDonough [EMAIL PROTECTED] wrote: Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) You know that the project wikis were always vapourware wikis (find it good or not)...lots of plans before the next release but only a small number of plans will make it into the final release. Likely the dates above were added before we changed to the June/December release cycle. -aj ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
--On 14. Juni 2006 10:59:09 -0400 Chris McDonough [EMAIL PROTECTED] wrote: So... you're saying that 2.10 isn't going to be released until December 2006, then? huh? The wiki says June/July...we are just running a bit late with the beta releases because Philikon needed some time for the ZPT integration..so why December? That would indeed make the deprecation period longer than 1 year, which seems to have been the intent. This makes no sense to me. Andreas pgpETOOh3GN7G.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 17:03 +0200, Andreas Jung wrote: --On 14. Juni 2006 10:59:09 -0400 Chris McDonough [EMAIL PROTECTED] wrote: So... you're saying that 2.10 isn't going to be released until December 2006, then? huh? The wiki says June/July...we are just running a bit late with the beta releases because Philikon needed some time for the ZPT integration..so why December? Buh oh geez, let's just forget it. ;-) That would indeed make the deprecation period longer than 1 year, which seems to have been the intent. This makes no sense to me. Let's start clean here. What interval of time is reasonable for the period between a to-be-removed piece of code emitting a deprecation warning and that code's removal? If you think 8 months is reasonable, it would make sense, for example, that the code in OFS.Application that looks for a module-scope '__ac_permissions__' in all products would be removed for 2.10 (as its deprecation warning currently states). If you think that's too short a time, then it's broken. Personally I think 8 months is too short a time, and I think it should be at least one year and I think most folks agree with this. I don't remember what the official policy is nor would I know where to find it. But if you agree with this, in order to have a full year's deprecation period, as far as I can tell, we'd need to make a policy that deprecations can only be done in in .0 releases. That would ensure at least a full year between the first deprecation and the code removal. Any other policy does not make sense if the goal is to have full-year-long deprecation periods. And at this point, IMO, a feature isn't really deprecated until it emits a warning. Older releases didn't emit deprecation warnings (partly because there was no warnings module), so basically *we tried not to deprecate anything* and we always strove (but only partially succeeeded) at full-bore backwards compatibility, cruft-be-damned. Things are better now, so we can deprecate stuff, but we still need to be consistent about how we do it. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. Ah, well, then we have two overlapping issues that causes this problemo: 1. We did not use deprecation warnings years ago. 2. methods issue deprecation warnings by mistake. (In fact, 2 is an effect of 1, as the warning comes because it was unclear what was deprecated.) This means that we in any case definitely should NOT remove methods until 2.11, if at all. :) So this is not a problem with deprecation period, time based releases or anything else, then. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Jun 14, 2006, at 12:32 PM, Lennart Regebro wrote: On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. Ah, well, then we have two overlapping issues that causes this problemo: 1. We did not use deprecation warnings years ago. 2. methods issue deprecation warnings by mistake. (In fact, 2 is an effect of 1, as the warning comes because it was unclear what was deprecated.) This means that we in any case definitely should NOT remove methods until 2.11, if at all. :) +1 to not at all from me ;-) So this is not a problem with deprecation period, time based releases or anything else, then. There are problems with the deprecation period, but only for __ac_permissions__ and meta_types assuming we choose not to deprecate 'methods'. If we were naive, we'd change the deprecation warning messages for __ac_permissions__ and meta_types in 2.9.4 from will disappear in 2.10 to will disappear in 2.11. But since we decided (in another offshoot of this thread) that it only makes sense to deprecate things in .0 releases, what *should* happen is that we should forget about all of this and add will disappear in 2.12 to what will become 2.10.0. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Jun 14, 2006, at 1:09 PM, Lennart Regebro wrote: On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: There are problems with the deprecation period, but only for __ac_permissions__ and meta_types assuming we choose not to deprecate 'methods'. The problem in this case being that we didn't use to issue deprecation warnings. ;) Yup, can't change history. In any case, I personally don't care if it's removed in 2.10 or 2.11. But since we decided (in another offshoot of this thread) that it only makes sense to deprecate things in .0 releases, what *should* happen is that we should forget about all of this and add will disappear in 2.12 to what will become 2.10.0. I don't understand that logic. Zope 2.9.0 issued deprecation warnings for these. Why should we not remove it in 2.11.0? That is two major versions later. You're right, sorry. I didn't realize the deprecations made it into 2.9.0; I thought they went in to 2.8.5+ and 2.9.1+ . Removing these in 2.11.0 is fine then. The 2.9 branch's deprecation warnings will continue to will say that all of these things will be removed in 2.10, which will be a lie. But that's OK, people will tolerate misleading deprecation warnings as long as what we do is actually more conservative than what it says we're going to do. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Time-based releases a good idea?
Paul Winkler wrote: On Wed, Jun 14, 2006 at 11:47:13AM -0400, Chris McDonough wrote: I think that's the sanest policy. So it's OK if bullshit gets called on people putting deprecation warnings into any .1, .2, etc through .9 releases, then? This seems like the only thing that can work. We can't expect people to upgrade to stable point releases (e.g. 2.8.5 from 2.8.4 or earlier) just to be able to see deprecation warnings. That makes perfect sense to me. +1 to no new deprecation warnings in stable third-dot releases. +1 to that too. No new deprecation warnings outside feature releases. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
