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

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chris McDonough wrote:
> On Wed, 2006-06-14 at 17:03 +0200, Andreas Jung wrote:
>> --On 14. Juni 2006 10:59:09 -0400 Chris McDonough <chrism at plope.com> 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.

+1.  A deprecation is a change in the feature set, which is *not*
appropriate in third-dot releases:  those releases have stability as a
primary goal;  cleanliness is *not* next to godliness in that context.

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


Tres.
- --
===================================================================
Tres Seaver          +1 202-558-7113          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEkC8w+gerLs4ltQ4RAlKVAKDDTlVZj4iUT7ZZzSiN7SoCS05TfwCgjcEl
Hh6RL4+6bAV4kAJPkMY1emM=
=LiMJ
-----END PGP SIGNATURE-----