v6 breaks some of my modules that want Perl v5.10 support

The move to semantic versioning and requiring v5.12 broke my release process for CPAN::Audit through Pod::Usage. This is also going to cause problems with PerlPowerTools this week. I expect it might affect several other modules I maintain when they need releases. This was partially warned about in #29.

Personally, I don't think the breakage is worth it for. Maybe it is, but I haven't seen the justification of it. I think that a highly upstream package such as this needs a lot more warning and review before it things go forward.

I don't really care about the old versions of perl myself, but people who use the stuff I maintain do. I'd like to not exclude some people if I don't have to.

First off, I'm very sorry that this came as a surprise. I am clearly not well plugged in to the Perl communication discussion forums and have had a lot of difficulty communicating this change to the people who need to know about it.

Here's where I attempted to send notice of this:

https://www.mail-archive.com/module-authors@perl.org/msg10950.html

This was the suggestion of the best forum after the earlier issue with bumping the prerequisite Perl version to 5.10 with the previous release. I do understand the difficulty with bumping the version of core modules such as this one, but I'm trying to trade that off against my ability to maintain the code, a lot of which is admittedly subjective.

My understanding was that the Perl community had reached a semi-policy on this topic, noted here:

https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/lyon-amendment.md

and discussed here:

https://rjbs.cloud/blog/2023/05/pts-2023-lyon-amendment-2-5/

which in my understanding gave the green light to this change up to Perl 5.16. I'm personally quite excited about being able to bump the dependency version to Perl 5.20 so that I can use function signatures; I've been slow to adopt them so far (and still have a lot of coding style cleanup work to do in podlators), but I think they will help maintenance in the long run.

I definitely do not want changes like this to come as a surprise, so if you could suggest places other than module-authors that I should notify, I would be very happy to do that. It was not my intent to avoid warning and review; any failings on that front are purely my lack of knowledge of how to go about getting that warning and review.

I would just to note that @rra raised the issue of the move to semantic versioning and 5.12 minimum version on the Perl 5 Porters list back in March, starting here: https://www.nntp.perl.org/group/perl.perl5.porters/2024/03/msg268093.html. And he has been very responsive to points that we have raised and nits we have picked. I acknowledge that that may be sub-optimal for downstream authors who may not be reading that list on a regular basis.

What do you think that v5.12 gets you in maintainability that v5.10 can't do? From the module-authors list, it merely sounds like you want to use new syntax. I don't think that justifies cutting off versions in a core module. Using Unicode property values in \p{} might be a justification and you need v5.12 for that.

If you are going to make a big change, talk about it everywhere. Hiding it in a virtually zero-traffic module-authors mailing list was really bad advice. Not only that, mentioning it only in one place is still bad advice. (FWIW, the p5p thread doesn't mention the minimum version changing that I can see).

There are many other places where a big change to a fundamental module would be useful and reach large audiences:

perl.com
blogs.perl.org
reddit.com/r/perl
Facebook community groups
Perl Weekly

MetaCPAN will show you your reverse dependencies (things that depend directly on your module). You should look through all of those and see which ones declare that their minimum version of Perl is v5.12. Pod::Usage, the one I care about, doesn't have any minimum version. Now it needs to declare one since depends on podlators.

We don't have a good way to denote that a distribution depends on a particular major version of a distribution and to ignore later major versions, and the tools will try to install the latest version. Since the change is likely a couple steps removed from the module they are trying to install, this is hard to figure out. Thus, a very tiny change at the top of the CPAN river can turn into a raging river of pain.

Beyond that, with a breaking change, you could have found all the CPAN distributions that would be affected (river of dependencies) and contacted all the authors directly, probably by raising issues in their repositories about the upcoming change. But, that's a big task and probably only worth it when you really, really need the change.

Even then, the time between March 25, 2024 and the time you released it as a production version is very, very short. This does not give CPAN Testers a chance to let me know that something is going to break. I'd suggest a period of several months before you make such a production release. Don't rush things at the end of a perl release cycle to fit it in, just like you don't push to prod right before the weekend.

I'd prefer you drop back to v5.10 support. It's sometimes ugly and way out of date, but it's the least amount of work for someone maintaining widely used components of other components.

If you want to abandon even more versions, let me know so I can stop using podlators, or fork it, or something else. I certainly can't use podlators if the minimum version is going to be v5.24.

Thanks for this substantial reply. This helped me understand your position.

Thus, a very tiny change at the top of the CPAN river can turn into a raging river of pain.

I think this is your core point. I think one of three things has happened, and I'm trying to understand which it is:

I have misunderstood the implications of the Lyon Amendment. The implication of the decision to drop support for Perl versions older than 5.16 was, I thought, that the CPAN installation tools will become very difficult to use with Perl versions older than that point. Therefore, for any version of Perl older than 5.16, this sort of breakage should be expected as core Perl toolchain packages drop support for older versions, and people who want to keep using those versions of Perl will need to provide the separate CPAN view discussed in the above blog post or investigate other workarounds. But maybe I have gotten this completely wrong?
I have understood the Lyon Amendment correctly, but you disagree with it.
This is a problem that was not anticipated by the Lyon Amendment and the Lyon Amendment needs to be rethought.

Do you know which of those is the case? I'm hearing different things from different people, and I'm trying to figure out if I just misunderstood or if I'm in the middle of an argument.

There are many other places where a big change to a fundamental module would be useful and reach large audiences

It feels to me like the big change was that the big change was the Lyon Amendment, and that's the thing that should be widely announced since that will have way broader implications than Pod::Usage. But that assumes that I am understanding this correctly. I largely relaxed about trying to advertise this change when I found out about the broader toolchain policy, since I thought that I was fitting into that and that would be widely announced. That may have been a bad assumption.

Several of those forums are not ones that I'm personally willing to use, but I can at least try to get a notice into perl.com and Perl Weekly and will remember that for the future. Thank you!

This does not give CPAN Testers a chance to let me know that something is going to break.

This is a very good point. I should have, but had not realized that CPAN Testers would do this with unindexed versions. I've never used alpha releases of my modules (some of my habits date back to the early 2000s, I fear) and should start using this for modules that are way upstream. This is my fault for not having kept current with good maintenance practices. I will adopt this practice in the future.

Pod::Usage, the one I care about, doesn't have any minimum version. Now it needs to declare one since depends on podlators.

I believe this both won't help and is semantically incorrect, but it's possible that I'm missing something.

The current metadata for Pod::Usage is correct: it only requires Perl 5.6, and it works with any version of Pod::Text later than 4.00. This continues to be as true today as it ever was, and it would arguably be semantically incorrect for Pod::Usage to increase its minimum Perl version. You can download and install it today on Perl 5.6, presumably, if you already have a supported version of podlators installed.

The problem is caused by the limitations of CPAN: it only indexes the latest version, and therefore it tries to install the latest version of all dependencies. As a result, attempting to install Pod::Usage on Perl 5.10 with a cpan tool fails because podlators cannot be installed. But if the minimum version of Pod::Usage were bumped to Perl 5.12, wouldn't you get the same behavior? Pod::Usage would fail to install. Maybe your point is that the error message would be more obvious? But I don't think that change would change anything about where Pod::Usage can be successfully installed, and it would prevent Pod::Usage from being installed manually on systems where it would install just fine.

MetaCPAN will show you your reverse dependencies (things that depend directly on your module).

I did not look exhaustively at all of the reverse dependencies, but of the ones that I looked at, Pod::Usage was the only one with this specific problem. Of the other reverse dependencies that I looked at, all of the dependencies were spurious.

Most of these appear to be due to a Dist::Zilla plugin which apparently adds a Pod::Man => 0 dependency to many packages. I haven't yet figured out if this is still the current behavior. This dependency is a bad idea given the behavior of tools installing packages from CPAN, since I believe they all have the problem that they cannot detect when dependencies are satisfied by core modules already included with Perl. This directive therefore tells those tools to always install podlators over top of the core modules. This is not a good idea; the local administrator can choose to install a newer version of podlators if they want better output, but other modules should only use dependencies if they truly need newer features or interfaces than were included in the version of Pod::Man and friends that were included in that version of Perl.

Therefore I think the best thing to do with all of these dependencies is to delete them, presumably by changing the code in Dist::Zilla or a plugin that added that dependency. The same is true of the manually added dependencies that I saw. The dependency would only be meaningful for versions of Perl prior to 5.6, and (a) I am dubious anyone is still using those versions of Perl, and (b) podlators has not supported Perl versions older than 5.6 since 2015 anyway, so this is water long under the bridge.

What do you think that v5.12 gets you in maintainability that v5.10 can't do?

It's not that specific version increase that I care about, but the ability to continue to increase the minimum version so that I don't have to remember an ever-growing list of special rules I have to follow to write in an old dialect of Perl, and so that I can slowly, over time, modernize the Perl style of all of my modules.

Modernizing code is something that brings me a great deal of joy, and it is part of what makes me willing to maintain my Perl modules as an ongoing hobby. After fixing some reported bugs, I reward myself by refactoring some code and updating coding style. I do this very slowly because my time is very limited, but each release has some small iota of progress. I suspect this may sound odd, but this is how my brain works. I personally am willing to be fairly conservative, but I'm not willing to commit to supporting old versions of Perl forever, and your objections don't give me a timeline at which I can drop support for 5.10, and 5.12, and 5.14, etc.

Now, this may mean that this makes me unqualified to be a core module maintainer. If folks feel that way, please say so: I won't be offended! I've been maintaining podlators essentially by myself for 25 years, and that's a really long time to spend on one project. If the Perl community feels that I've drifted away from the community's values and would like me to hand podlators over to a different maintainer who is more in line with those values, that is a totally okay thing to say and I will weigh that feedback carefully.

My day job doesn't use Perl at all, so this is purely a personal hobby that I pursue in a fairly limited window of time. There are some things that I can't realistically do (such as make changes to the dependency management of numerous other modules before I can make a change to podlators), and some things that I'm not willing to do because it would reduce my enjoyment of this hobby sufficiently that I'd lack motivation to continue it. I don't mean this as any sort of threat; I'm just trying to be very honest about what I can and can't do and putting all of the implications on the table.

It is truly not my goal to make problems for you, but I also don't want to maintain support for every version of Perl forever. At some point this becomes software archeology, and that's not something I enjoy or am willing to do. I'm not sure where the right compromise is, which is why I was relying on the Lyon Amendment as a guide.

Thinking about this some more, and poking around a bit, I'm now not sure where I got the impression that the CPAN installation tools wouldn't detect dependencies already satisfied by Perl core. I think I may have gotten that entirely wrong, in which case the podlators dependencies other than Pod::Usage should be harmless since they will already be satisfied by Perl core except for versions of Perl that are even older than the ones we're discussing.

tl;dr I'm closing the issue because I think I have a path forward, that we have both articulated our positions, and life goes on.

Zeroth, I think you are fine for being a core contributor. I've known about you forever, you're a reasonable person, and I think you generally do good work. However, I think the vocal portion of community has generally failed you. You asked for guidance and did what you were told. It's just that what you were told came from a unified viewpoint that coalesced around the people who managed to stick around certain parts of the community after the dissenters were chased off. This is not just a Perl thing or a graybeard thing; it's a problem in other communities (looking at you Rust, but lots of other communities have the same problem).

First, I think that not declaring a dependency on a core/dual-lived module like Pod::Usage might solve my problem. If a cpan tool does not think there is a dependency, it won't try to install the latest version and the latest versions of its dependencies. This pushes the complexity elsewhere though, since tools to discover and declare dependencies (such as my Module::Extract::Use) now need to know to not declare Pod::Usage even though I explicitly use Pod::Usage.

This is also why Pod::Usage needs to declare a new minimum version. The one you already have you already have, so you don't care about installing it. The one you want to install now will only work on v5.12 and later because of a dependency. Note that my CI failures come from cpan and cpanm trying to install the latest podlators on old Perls even though the minimum requirements of Pod::Usage should have already been met. This is the CPAN tool problem that we can't fix, and even if we could, the fix wouldn't be available to old installations of cpan/cpanm (so, virtually unavailable everywhere). If Pod::Usage could tell people that it now will fail to install unless you have v5.12, people will see the problem. You noted this in Dual-Life/Pod-Usage#25, with various options to handle it.

Second, I think that moving from old perl syntax to new perl syntax requires you to know more instead of using what you already know. That's just my feeling and I think we understand each other on that even if we disagree.

For the situations you outlined about the Lyon Amendment, I think it's probably a little of all three.

I've always thought the Lyon Amendment was about the core toolchain, the minimal set of modules to install modules, and not anything outside of that. This is the idea of Perl's Standard Library (that is the opposite of Python's "batteries included" idea). That doesn't mean Lyon can't apply outside of the core toolchain, but the reasoning for it was grounded in actual problems the toolchain had in dealing with things such as encodings, newer versions of Unicode, and so on. For the most part, this has not been a problem for whatever reason. In most of my CI stuff, I install the latest ExtUtils::MakeMaker despite the Perl version and haven't seen breakage. However, that might mean that those tools go to perhaps unreasonable lengths to be backward compatible ($^] and all that).

Some people see Lyon a free for all to convert the old working syntax to new working syntax even in the absence of a problem, while others see that as permission to fix some problems where a new minimum version of perl is the only way to get there.

For legacy software (stuff I released forever ago), I want to support the earliest versions I can. That's usually v5.8, but it tends to be whatever a reasonable version of perl was at the time. For stuff I write today, I can start with current perl or something earlier, such as v5.26 (indented heredocs!), because there is no user base to support yet. I think I generally start with v5.30 for new stuff right now because that's what is likely available as the system perl for up-to-date systems.

I see this as the tension between two sorts of developers in open source:

I have a hobby of writing code. I will spend X hours this week doing that. I will spend my X hours this week modifying this particular code base because I'm going to spend X hours this week modifying something so why not this thing?
I support this thing and it has a problem. I want to solve this with the least amount of work so I can do other things I also want to do. That something else might be watching grass grow.

It's difficult for me to express 1) without letting some bias seep through, but just because I see problems doesn't mean it's wrong. We need all types. But, there is a subset of the community that is going to do work because they are going to do work even before a problem is articulated, analyzed, and valued. For example, many distros have been rescued from absent maintainers then converted to Dist::Zilla, without any increase in value to the end user. Or, modules converted to Moose without any increase in value to the end user. And so on. These sorts of things create a lot of work for downstream people even though it's likely the changes provide no additional value to the end user. And, in my opinion, changing to semantic versioning (although podlators has flipped a couple times) is that class of change.

Those two types of developer philosophies are really expressions of who is primarily important in open source and who should be centered in the activity:

Center the developer
Center the end user

This can lead to all sorts of interesting conversations. The original idea of open source, in the Stallman sense, was that I have software that you provided because I paid for it (came with the printer, whatever), but I can change it to work with this new printer I have. The current idea of open source is not that though; it's that someone provides free stuff and I open issues to make them change it, and oh, do it for free, right now. Then I will fork it, rename it, and make it a paid AWS service :)

rra / podlators

v6 breaks some of my modules that want Perl v5.10 support #35