Opened 11 years ago

Closed 5 months ago

#1216 enhancement closed fixed (fixed)

Deprecation policy

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

Description (last modified by glyph)

Related tasks:

Change History (16)

comment:1 Changed 11 years ago by jml 

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 11 years ago by hypatia 

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

comment:3 Changed 11 years ago by jml 

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 11 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 10 years ago by jml

  • 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 10 years ago by hypatia

  • Cc hypatia removed

comment:7 Changed 9 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 9 years ago by radix

  • Milestone set to twisted-8.0

comment:9 Changed 9 years ago by radix

  • Milestone changed from twisted-8.0 to regular-releases

comment:10 Changed 8 years ago by jml

  • Owner changed from radix to jml
  • Status changed from new to assigned

comment:11 Changed 8 years ago by jml

  • Keywords deprecation-policy added

comment:12 follow-up: Changed 8 years ago by 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.

comment:13 Changed 8 years ago by jml

#3262 is not part of the deprecation policy work.

comment:14 Changed 6 years ago by <automation>

  • Owner jml deleted

comment:15 in reply to: ↑ 12 Changed 4 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 5 months ago by adiroiban

  • Resolution set to fixed
  • Status changed from assigned to 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.