develooper Front page | perl.perl5.porters | Postings from February 2023

Re: Deprecation doesn't mean we have two release cycles beforethings break.

Thread Previous | Thread Next
From:
demerphq
Date:
February 28, 2023 11:38
Subject:
Re: Deprecation doesn't mean we have two release cycles beforethings break.
Message ID:
CANgJU+Vaomx9bHO+7PGX0Rqgb9xMMaAR5q05AFn33Ds0cseScg@mail.gmail.com
On Tue, 28 Feb 2023 at 12:22, sisyphus <sisyphus359@gmail.com> wrote:

> 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.
>

That is still a change we or the author have to make to the distribution.
If the author is AWOL, then the toolchain is broken for that release.


>
>
>> 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.
>

That is MUCH easier said than done. It is generally much easier to fix D
than to fix A to ignore that specific warning. (IMO)


>
> Is that about it ?
> Are there any other scenarios we need to consider at this stage?
>

The main point is that we need to do something, immediately. When I brought
this up on #p5p irc I got a lot of  pushback that we have two years. The
point of this mail is that we don't. From the moment we release the
deprecation warnings the CPAN river is impacted. If  amodule is high up in
the river and doing what i think many would consider "responsible testing"
and validating their code runs warning free then the distribution will be
broken, even if strictly speaking the code is just fine albeit noisy with
deprecation warnings.


>
>
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.
>

Sure, but it is still a BBC. We still have to do something. We can't just
pretend we have two years to go before we can do something. Until it is
actually fixed upstream the dependency is broken from a CPAN perspective.


> Have the changes that trigger these issues already been merged into blead ?
>

Yes. One is already released in 5.37.9, and one will be released with
5.37.10 and is present in 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 ?
>

Yes indeed. Although I have already filed bug reports (and patches) for a
lot of Father Chrysotomos'es modules (aka SPROUT aka @cpansprout), he was a
proud (ab)user of apostrophe as a package separator.  I have not fixed all
of them however, the ones lower down in the river rating on metacpan I have
not checked. It would be nice if we could get that list regenerated by
author.

cheers,
Yves
-- 
perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About