[Zope3-dev] Re: Deprecation period (was Re: BBB and Deprecation Warnings)

[Philipp von Weitershausen]

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