[Zope-dev] Re: Time-based releases a good idea?

[Andreas Jung]

--On 14. Juni 2006 11:24:45 -0400 Chris McDonough <chrism at plope.com> wrote:

>
>>
>> >  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?

The general rule for Zope 2 + 3: 1 year = 2 full major releases according 
the current half-yr schedule

>
> If you think 8 months is reasonable,

I never said something like that. I even did not comment on the this issue
since I have very little insight about the internals at this point. 
Anything deprecated in 2.9 can officially be removed in 2.11. It should not 
happen that a deprecation happens after the final release.


> 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.

See above..I fully agree..

> 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.


jup


>
> 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.


A feature should never be removed if there is no reasonable replacement. A 
feature should only be removed if it is obviously broken and unfixable, 
totally out-dated and unmaintable.

Andreas



-- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: info at zopyx.com - Phone +49 - 7071 - 793376
E-Publishing, Python, Zope & Plone development, Consulting
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20060614/e4b35f2a/attachment.bin