Opened 13 years ago

Closed 2 years ago

#1216 enhancement closed fixed (fixed)

Deprecation policy

Reported by: Jonathan Lange Owned by:
Priority: normal Milestone: totally automated release infrastructure
Component: release management Keywords: deprecation-policy
Cc: radix, spiv, Jonathan Lange, Glyph Branch:
Author:

Description (last modified by Glyph)

Related tasks:

Change History (16)

comment:1 Changed 13 years ago by Jonathan Lange 

It'd be kind of nice if we had a deprecation policy written up.  Doesn't have to
be big and hardcore, but just some notes on what we are aiming for, and some
guidelines on how to get there.

comment:2 Changed 13 years ago by hypatia 

Well, what are people *actually* doing? That's always a good basis for a policy
discussion...

comment:3 Changed 13 years ago by Jonathan Lange 

I *think* the advice on the street is "Deprecate in Release 2.n, remove in
Release 2.(n+1)"

Deprecation is done by issuing a DeprecationWarning using the warnings module.

This sounds fine to me :)

comment:4 Changed 13 years ago by hypatia 

Perhaps with some guidelines to the effect that modules where this is regularly
going on or has recently gone on should be marked unstable?

comment:5 Changed 11 years ago by Jonathan Lange

Cc: Glyph added
Keywords: documentation removed
Owner: set to radix

glyph says, "We should have a time-based deprecation policy." (See #2352)

Also, having the policy means documenting and enforcing it.

comment:6 Changed 11 years ago by hypatia

Cc: hypatia removed

comment:7 Changed 10 years ago by Glyph

I've written up a proposed compatibility policy. I think the real remaining challenge here is to get our release process back on track so that we can have an official point where it takes effect; and perhaps also to clean up the deprecation warnings listed there.

comment:8 Changed 10 years ago by radix

Milestone: → twisted-8.0

comment:9 Changed 10 years ago by radix

Milestone: twisted-8.0 → regular-releases

comment:10 Changed 10 years ago by Jonathan Lange

Owner: changed from radix to Jonathan Lange
Status: new → assigned

comment:11 Changed 10 years ago by Jonathan Lange

Keywords: deprecation-policy added

comment:12 Changed 10 years ago by Jonathan Lange

#3262 #3263 #3264 #3265 and #3266 have all been filed in response to the new thread at: ​http://twistedmatrix.com/pipermail/twisted-python/2008-April/017497.html

They have all been tagged with "deprecation-policy" and assigned to me.

This ticket is now functioning as the master ticket for the new work. I'm happy to consider #1216 superceded by the new keyword.

comment:13 Changed 10 years ago by Jonathan Lange

#3262 is not part of the deprecation policy work.

comment:14 Changed 7 years ago by <automation>

Owner: Jonathan Lange deleted

comment:15 in reply to:  12 Changed 6 years ago by Glyph

Description: modified (diff)

Replying to jml:

#3262 #3263 #3264 #3265 and #3266 have all been filed in response to the new thread at: ​http://twistedmatrix.com/pipermail/twisted-python/2008-April/017497.html

They have all been tagged with "deprecation-policy" and assigned to me.

This ticket is now functioning as the master ticket for the new work. I'm happy to consider #1216 superceded by the new keyword.

I've updated the description to reference these tickets so that it'll be a little easier to find them.

comment:16 Changed 2 years ago by Adi Roiban

Resolution: → fixed
Status: assigned → closed

I would say that with #8082 we now have an official deprecation policy.

#3266 is there, but it talks about a very strange API ... and for me, the simple Vesion() object is enough

Note: See TracTickets for help on using tickets.