Front page | perl.perl5.porters |
Postings from February 2012
On Sun, Jan 29, 2012 at 09:21:07PM -0500, David Golden wrote: > I expect that 99.9%+ of Perl users do not build dev releases (much > less test code on them), as much as we encourage them to. Thus, I > don't expect anyone to react to a deprecation warning until the stable > release in which deprecation warnings start. (Thankfully, we have > Andreas who regularly smokes blead because that's most of the "live > code" smoking we get.) Agree. But it's incredibly useful. > So while I don't like "risky" code late in the dev cycle (by which I > mean things that are complex and might have surprising bugs revealed > in testing), I don't see any reason why deprecations can't be > introduced right up to the code freeze, since the only point it really > affects most users is when the stable release is done. I can see a couple of related small risks 1) we don't like shipping a new stable release with known "embarrassing" things in CPAN modules. Adding new speed bumps for CPAN authors near our release time reduces their time to update their code. 2) we don't always *find out* about problems immediately. Specifically, making the long-deprecated defined (@array) finally warn caused a test failure in PPI, because one of its pre-requisite modules now issued a warning, which confused one of PPI's tests which parsed output. That upstream module *didn't* fail tests. In this case, I don't think it was a new change in the upstream module. But if new code in upstream modules interacts with our changes in ways that *only* effect downstream modules, then that's not going to get spotted in any timely fashion by a CPAN smoker that prioritises testing new modules. It also gives us less time to change our mind. So I think adding things later increases risks of problems slightly. But not hugely. Nicholas ClarkThread Previous | Thread Next