Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
For me one year is fine as a deprecation period. I feel that sites should be kept stable when working, and then, after maybe a year or two or more, when needed, moved to a new and updated system. If you then have special software, you'll need to update it. If we want those types of updates to work without software changes, then we need deprecation periods that are 3-5 years, which I find wholly unreasonable. I tend to think two years is a bit long, but 1, 1.5 and 2 years are all acceptable to me, though I definitely would prefer 1 year. That also coincides nicely with the 2 version policy we have run so far. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Benji York wrote at 2006-1-4 14:22 -0500: >Dieter Maurer wrote: >> Jim Fulton wrote at 2006-1-3 14:41 -0500: >>>I think 12 months is a bit short. I don't think the backward-compatibility >>>code >>>is that burdonsome, once written. What do other folks think? >> >> If the backward compatibility period gets shorter, >> we will skip more and more releases because of the increased burden >> to get our applications running again... > >Does that mean that you think 12 months is too short, just right, or >nearly too short? I answer here as a user (of the Zope[3] framework) not as a (framework) developper. As a user, I prefer the deprecation period to be as long as possible. I cannot dictate the developpers what deprecation period they choose but I can refrain to upgrade. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Tim Peters wrote at 2006-1-4 14:51 -0500: >[Dieter Maurer] >> If the backward compatibility period gets shorter, >> we will skip more and more releases because of the increased burden >> to get our applications running again... > >Well, every new release will remove features deprecated N releases >ago, where N is presumably some constant whose value is being debated >here. That will be so in steady state whether N is 1 or 10 (i.e., the >value of N doesn't really matter to that): the pressure to recode >(and your temptation to skip releases) is related more to the >frequency of releases than to the length of the deprecation grace >period. In fact, whether I upgrade or not depends on the merits of the new version (with respect to that currently used) and the effort necessary for the upgrade. You are right that the (long term) average number of features removed in a given release depends on the time between releases but not the length of the deprecation period. However, a long deprecation period allows to cluster the renewal work. If the deprecation period is e.g. 4 releases, then I can 3 times upgrade without to worry about deprecations if I am ready to resolve all deprecation problems in the 4 th one. This increased clustering gives more flexibility to do the renewal work at times when projects are not to heavily pressing. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
[Dieter Maurer] > If the backward compatibility period gets shorter, > we will skip more and more releases because of the increased burden > to get our applications running again... Well, every new release will remove features deprecated N releases ago, where N is presumably some constant whose value is being debated here. That will be so in steady state whether N is 1 or 10 (i.e., the value of N doesn't really matter to that): the pressure to recode (and your temptation to skip releases) is related more to the frequency of releases than to the length of the deprecation grace period. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Dieter Maurer wrote: Jim Fulton wrote at 2006-1-3 14:41 -0500: I think 12 months is a bit short. I don't think the backward-compatibility code is that burdonsome, once written. What do other folks think? If the backward compatibility period gets shorter, we will skip more and more releases because of the increased burden to get our applications running again... Does that mean that you think 12 months is too short, just right, or nearly too short? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Jim Fulton wrote at 2006-1-3 14:41 -0500: > ... >I think 12 months is a bit short. I don't think the backward-compatibility >code >is that burdonsome, once written. What do other folks think? If the backward compatibility period gets shorter, we will skip more and more releases because of the increased burden to get our applications running again... -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Hi, Am Dienstag, den 03.01.2006, 14:41 -0500 schrieb Jim Fulton: > > As much as BBB code annoys me personally, I think maintaining a minimum > > compatibility window is necessary for an important class of user. > > I think 12 months is a bit short. I don't think the backward-compatibility > code > is that burdonsome, once written. What do other folks think? Based on the argument of Stephan that we might not remember how the deprecated feature worked, it might be hard to maintain it for a very long deprecation period. I think it might not be enough to just leave the code around but we'll have to do something to keep it working (with the same semantics) in the new version. But this is a case-by-case issue. I for myself think 12 months is ok. I wouldn't do a shorter period, but I won't ask for a longer period. On projects that are stable and work on a certain version of a platform we stopped upgrading the whole environment all the time anyway. Even during development. Cheers, Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: This is a digitally signed message part ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Deprecation period (was Re: [Zope3-dev] BBB and Deprecation Warnings)
Benji York wrote: Stephan Richter wrote: On Tuesday 03 January 2006 13:33, Benji York wrote: > As a corollary, it would be time now to remove the BBB that should be > removed for 3.3. Should we wait for 3.4? Following the rules above, if 3.3 will be released more than 12 months since the release of 3.1, it would be OK to remove the code now. Unfortunately, Zope 3.1 *final* was not released until 10/2/2005, so that 3.3 will be out before 12 months. 12 months seems like a good interval to me, not too long to be overly burdensome on the developers, but not so short as to be overly demanding of users. As much as BBB code annoys me personally, I think maintaining a minimum compatibility window is necessary for an important class of user. I think 12 months is a bit short. I don't think the backward-compatibility code is that burdonsome, once written. What do other folks think? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] BBB and Deprecation Warnings
Stephan Richter wrote: On Tuesday 03 January 2006 13:33, Benji York wrote: > As a corollary, it would be time now to remove the BBB that should be > removed for 3.3. Should we wait for 3.4? Following the rules above, if 3.3 will be released more than 12 months since the release of 3.1, it would be OK to remove the code now. Unfortunately, Zope 3.1 *final* was not released until 10/2/2005, so that 3.3 will be out before 12 months. 12 months seems like a good interval to me, not too long to be overly burdensome on the developers, but not so short as to be overly demanding of users. As much as BBB code annoys me personally, I think maintaining a minimum compatibility window is necessary for an important class of user. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] BBB and Deprecation Warnings
On Tuesday 03 January 2006 13:33, Benji York wrote: > > As a corollary, it would be time now to remove the BBB that should be > > removed for 3.3. Should we wait for 3.4? > > Following the rules above, if 3.3 will be released more than 12 months > since the release of 3.1, it would be OK to remove the code now. Unfortunately, Zope 3.1 *final* was not released until 10/2/2005, so that 3.3 will be out before 12 months. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] BBB and Deprecation Warnings
Stephan Richter wrote: > So let's make the deprecation support also time-based. What time would > you prefer? I would prefer two releases and a minimum of 12 months. That way if the time-based releases slip, we still guarantee two releases with backward compatible code. If we release more often, we guarantee at least 12 months of backward compatibility. > As a corollary, it would be time now to remove the BBB that should be > removed for 3.3. Should we wait for 3.4? Following the rules above, if 3.3 will be released more than 12 months since the release of 3.1, it would be OK to remove the code now. -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] BBB and Deprecation Warnings
Hi all, now that we switched to time-based releases, it seems that our policy to support old API for two more 3.x releases is not appropriate anymore. Two release cycles are now only 12 months long, which seems a bit short. So let's make the deprecation support also time-based. What time would you prefer? - 12 months (2 releases) - 18 months (3 releases) - 24 months (4 releases) Note that there is a tradeoff for longer deprecation times. The longer a feature is gone, the more likely it is that you will not remember how it works and thus be unable to help people. For example, do you still remember how the old local component registry worked? I don't! :-) As a corollary, it would be time now to remove the BBB that should be removed for 3.3. Should we wait for 3.4? Or make an exception for this BBB code, since it was written before timely releases came around? Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
