Front page | perl.perl5.porters |
Postings from October 2009
Citeren jesse <jesse@fsck.com>: > >> I'd like us to adopt a policy of actually removing things that we deprecate. >> I'd like it to be consistent - everything first deprecated "now" is removed >> "then". Otherwise people will become complacent about rewriting things - >> "oh, they don't really mean it" >> >> As I'd also like it to be "1 major release" between "now" and >> "then", I don't >> like the idea of deprecating something for 5.12, but only removing >> it in 5.16. > > It's important to me that we put calendar time into the mix here. If > we deprecate something in 5.12 and 5.14 comes out 9 months later (not > likely, I know), that doesn't feel like sufficient notice to the world. > > Maybe something like "Deprecated features may be removed from blead 24 > months after a shipped maint first warns about them"? > I'm not convined that is a good idea. The situation I think of: Timeline: a) *something* is marked as deprecated in perl-5.11.0 b) perl-5.12.0 is released with the deprecation warning for *something* c) development on perl-5.13.0 begins Now the issue: when is the actual code removed from perl-5.13.0? As far as I can see it can only be removed from perl-5.13 24 months after perl-5.12.0 is released since the release date of perl-5.14.0 is (currently) unknown. If the removal of the deprecated functionality is nessesary to do X then the date when it is removed is important since only then the work can being... Yes the work could happen immediatly on a topic branch and then merged back 24 months after the release of perl-5.12 but that imposes two risks: a) the branch might be completly out of sync b) when the merge happen the person that wrote the code might have forgotten all the details Best regards, BramThread Previous | Thread Next