Front page | perl.perl5.porters |
Postings from January 2012
David Golden <xdaveg@gmail.com> wrote: :On Mon, Jan 30, 2012 at 3:06 AM, <hv@crypt.org> wrote: :> I consider this deprecation risky: Further, I consider there is a non-zero :> probability that once we try it we may find that the practice we wish :> to deprecate is so widespread that we reconsider our approach. :> [snip] :> Attempting this at the start of a cycle would give us the space we need :> to discover whether it's a really bad idea. : :Apologies in advance for "picking on you", but this is a good example :of the confusion of issues/arguments that I would like to avoid. Fair enough: I foolishly attempted to strengthen my argument by throwing additional risks in, but instead managed to obscure it so effectively that my main point was exactly the bit you snipped: :In particular, this isn't some practice that was previously dubious or :"always broken" - as far as I know, the norm and received wisdom has :always been "don't escape what doesn't require it". In recent years we have deprecated a number of dubious practices, that were always either broken, or so hard to use correctly that the vast majority of uses were broken. For such cases, it is IMO reasonable to say "we're going to cause you some pain now, but it's for your own (immediate) good - chances are what we're pointing out to you was in any case a bug in your code". This is not such a case. The benefit to the user is much more nebulous and long-term, and is in large part no more than the spillover effect of the benefits to p5p (which is not to be underestimated, but will be hard to communicate). :(b) "a non-zero probability that once we try it we may find that the :practice we wish to deprecate is so widespread that we reconsider our :approach" : :I argue that we have no way to know this during the development cycle :beyond the sort of "grep/smoke CPAN" approaches already done. This is :only something we'll find out after a stable release when the broader :userbase starts to use it (which might not happen for years). This is :not an argument to delay; this is an argument not to do it because of :the risks involved. : :(c) "Attempting this at the start of a cycle would give us the space :we need to discover whether it's a really bad idea." : :This *is* an argument for delay, but much as with (b), I don't think :it's legitimate for the same reason I cited above. I see (c) as a way to discover (b) with less pain for our users. The alternate proposal of 3-step deprecation (augmenting (c) with a "notice of intent" in the imminent release) works even better, as far as I'm concerned. Better still would be means, mentioned in that notice, for users voluntarily to enable the future deprecation warning. It is true that we rarely find out about problems a proposed change would cause from the wider userbase without a release. I see that, in this case, as an argument for greater caution, and for putting more effort into finding new avenues for communication and/or mitigation. :Thus, if your recommendation is "not now", then only (a) seems to have :merit. Alternatively, if you're argument is "never", then only (b) :seems to have merit. If many people feel the same either (a) or (b), :then it probably does rise to the level of "controversial feature". My recommendation is "not now", on the strength of current information. If further information, such as greps and CPAN smokes, were to show that it is a much smaller issue than that initial test run implied, it might be more justifiable. HugoThread Previous | Thread Next