Sorry for the double post, I accidentally hit send too early. I've been subject to the Django versioning/deprecation process for some time, and I agree with Amber. In practice, I usually pin Twisted apps to the version deployed when I hand them over to a client, and only install point releases until the next time I do major work/maintenance.
But the size of the Twisted codebase can be a challenge as well as an asset, so any work towards removing old cruft is a great initiative. -Phil sent from my phone > On Oct 25, 2015, at 8:48 PM, Amber Hawkie Brown <[email protected]> > wrote: > > 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-release-deprecation-policy), > 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 > _______________________________________________ > Twisted-web mailing list > [email protected] > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web _______________________________________________ Twisted-web mailing list [email protected] http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-web
