Hi everyone, As many know, one of the things that makes the Twisted project so unique is our conformance to our Compatibility Policy. This policy means that users of Twisted can freely upgrade between versions with all incompatibilities being warned about before causing code to break. However, for a while, one part of the compatibility policy has caused issues - what we do with code that has been deprecated for a long time, and at least the release + 2 & 1 year after. The existing policy states: "Removal should happen once the deprecated API becomes an additional maintenance burden. For example, if it makes implementation of a new feature more difficult, if it makes documentation of non-deprecated APIs more confusing, or if its unit tests become an undue burden on the continuous integration system. Removal should not be undertaken just to follow a timeline." This makes the only reasonable cause for any code being removed from Twisted is if it is a maintenance burden, but does not take into account the effect that keeping large amounts of deprecated code has on new, existing, and future Twisted users. It does specify that it should be removed if it makes documentation of non-deprecated APIs confusing, but by its very existence, it makes what should be "best practice" more confusing -- especially if the deprecated API is "simpler" at first glance, but was deprecated because of vast underlying issues, Discussions have come to the conclusion that the exact reverse of this policy should be instated: "Removal of code should occur as soon as the deprecation grace period has ended." The reason for this is that a leaner Twisted is a better Twisted -- we should strive to not break existing applications, but we have the deprecation policy in place to ensure that breakage is, if all goes to plan, never out of the blue. Less code surface means that Twisted is easier to learn for new users and Twisted-using projects onboarding new people, easier to use for established users with a clear best practice, and easier to maintain because the codebase is not a web of things we deprecated and then never removed. We believe this change benefits everyone. This is also similar to the deprecation policy of another time-based releasing project, Django (https://docs.djangoproject.com/en/1.8/internals/release-process/#internal-re...), where releases are every 9 months and code is *always* removed in Release where deprecated + 2, giving them a deprecation grace period of up to 1 and a half years. If you have any opinions on this change, please let me know, and we'll take it all into account before changing the policy. Twisted Regards, Amber "Hawkie" Brown Twisted Release Manager