v5.37's deprecations

Front page | perl.perl5.porters | Postings from April 2023

Thread Next

From:

Ricardo Signes

Date:

April 9, 2023 15:02

Subject:

v5.37's deprecations

Message ID:

02cf15ff-a928-4208-a1bc-7e00690c2809@betaapp.fastmail.com

On Friday, I wrote:
> Part of this is going to be "decide what we do with the question of warnings on smartmatch and the old package separator." I will post a separate thread about that issue. My take is "I really hope we can still ship those changes, but we may revert, and the question (to me) is not about *whether* we see CPAN 'no warnings' tests fail, but *which* ones." Expect to see that email sometime today.

Well, I didn't send it Friday or yesterday, but it's still "today" here, so here's that email you were waiting for.

*tl;dr*: I would like to carry out the deprecations as committed, although I think the smartmatch one is more questionable. I would like to hear from more of the core team about this.

The `'` deprecation went into v5.37.9, before the contentious change freeze. The smartmatch deprecation went into v5.37.10, after. So, starting from the most bureaucratic principles, the smartmatch one is more questionable, procedurally, if it is considered contentious.

Of the 38 open BBC tickets, 12 are about smartmatch. I think zero are about the package separator.

I've heard a bunch of arguments on both sides, and I want to sum up what I think the best ones (imho) are:
• we *should* deprecate these now, because code that can't be readily updated to *at least* add "no warnings '...'" is dead, and we shouldn't wait on dead code
• we *shouldn't* deprecate these with short notice, because once we know what's broken, people can take some time to initiate a takeover request in line with the PAUSE operating model <https://pause.perl.org/pause/query?ACTION=pause_operating_model>, which takes "several weeks"
I lean more toward the first one taking priority. The important question for me is what the impact on CPAN distributions seems to be? So far, it seems very small, basically affecting leafs. Further, it's often leafs that are disabling experimental warnings.

The other way of looking at the question, for me, is: *cui bono*? Who benefits? I think that it's something like this:

If we strike the deprecation, there is a concrete benefit to a so-far theoretical populace. People who use the will-fail-tests distributions and who also upgrade to v5.38 before their upstream dependency is upgraded. Do these people exist? Unclear. Are we creating a hassle for them by shipping a v5.38 that causes test failures upstream? Yes. Striking or delaying the deprecation eliminates that hassle.

If we keep the deprecation, there is a nebulous benefit to real people. People who are working on perl5 itself, who want to believe that change can still occur, will see it. They will see that their actual work isn't held back by hypothetical audiences whose problems are easy to address.

I realize my biases are showing, here, but I can't help but imagine that the alternative to "ship the warning" is:
• we delay the warning until 5.39.1, then ship it
• the same distributions are broken and a few more turn up
• between June 2023 and April 2024, two of them get fixed
• we ship in April 2024 with nearly no change in the conditions around ~~
• …except that we delayed a year
I don't see any evidence that we should remove the deprecation of the old package separator to avoid downstream havoc in v5.38.0. Smartmatch is more on the fence, but I'm not convinced. What does the rest of the team think?

--
rjbs

Thread Next