Front page | perl.perl5.porters |
Postings from February 2023
On Mon, Feb 27, 2023 at 9:17 PM demerphq <demerphq@gmail.com> wrote: > There seems to be this idea that if we deprecate something that we have > two release cycles, IOW, two *years*, before we have to get stuff fixed, > and that the only code which might be broken by the deprecation is code > that use fatal warnings, which we generally advise people not to use. > IMO, in this case a suitable fix is to have the fatality of the warnings disabled. > But that isn't correct. Odds are *very* likely we get CPAN breakage from > the very moment we deprecate something, as many modules test to see if they > generate warnings when they run. This can be transitive breakage with > "action at a distance", where distribution A uses B uses C used D which > uses a deprecated feature, and only A actually fails test because it tests > for warnings but B and C and D do not. > IMO, in this case a suitable fix is to have distribution A's test suite modified to accept or ignore the fact that module D presented a deprecation warning. There's no need to modify module D. Is that about it ? Are there any other scenarios we need to consider at this stage? The first thing to do would be to file bug reports against the affected modules - ie either because they fatalize warnings, or because their test suite overlooked the possibility of "action at a distance". After that, what we do depends upon whether the registered maintainer co-operates, or responds but won't co-operate, or doesn't respond. Have the changes that trigger these issues already been merged into blead ? If so, I'll start checking the distros listed at https://github.com/Perl/perl5/issues/20863 in the next day or so, and file bug reports about the impending changes as appropriate. Is that a sane way to start ? Cheers, RobThread Previous | Thread Next