Jim Fulton wrote: >> 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?
I think BBB code can become burdensome when it hinders further refactorings. I also think 12 months is a good compromise. Most people here don't seem to mind 12 months, though we've only involved Zope 3 people so far. Zope 2 will see far more deprecation in the future than Zope 3. Another two things I think are important to be discussed: * If we have several deprecation periods (12, 18, 24 months perhaps), we need a well-defined policy on when to use which period. I for one would argue that we should just stick to one deprecation period, 12 months, to avoid that problem. * The deprecation periods need to be synced with release dates. For example, let's say I refactor something in Zope 3 trunk and deprecate it now in January. It gets the label "Deprecated and to be removed in 12 months". This doesn't mean this is 12 months from now, it means it's 12 months from whenever this code will be released, in this case June 2006. Perhaps the deprecation API can be extended to support this, e.g.: >>> zope.deprecation.deprecate("component", "message", ... release='Zope 3.3', period=12) This would mean the deprecation message would be valid for 12 months after the 'Zope 3.3' release (the deprecation framework would know the date of the Zope 3.3 release). Philipp _______________________________________________ Zope3-dev mailing list Zope3firstname.lastname@example.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com