With the release of v5.14, official support for v5.10 ended. The new policy provides two years of official support for any stable release, plus an additional year of "critical security fixes only" support.

I'd say let *them* check it. Then you can either backport it, ask them to provide a back-compatible patch, or add a version requirement.

> I'm pretty open to a patch or a request if I can change a minimum without having to change how the code is written,

As long as this is the case, I'm fine. But e.g. I remember trying to play with parsing some stuff with Marpa a few years ago on 5.8, submitting a patch to remove trivial uses of "given" and "//", and being blown off.

I just wish authors would develop for whatever they had installed, without specifying a minimum (modulo "feature", of course), then bump up the minimum based on test results and bug reports.

(And yes, to my shame, I should have written "usable by *fewer* people" in my previous post.)

All of the code exercised by Mojolicious's tests apparently works under 5.10.0 semantics. IMHO only the simplest of smart-matches work in any sane way; if your code behaves differently under 5.10.0 and 5.10.1 semantics, it's using esoteric smart-matching. That said, users are always free to type "use Mojolicious; use feature ':5.12'", right?

> I spoke to Sebastian Riedel for you, and he said he'd be happy to take a test patch that makes it clear the contract with the user is to export the *5.10.1+* version of the given/when and ~~ semantics by failing on 5.10.0 so that nobody else comes to the same misunderstanding you did.

Thanks for taking the time, but the current situation seems more useful. All their tests still pass, so I'll just stick to the one-line local patch.

Re LWP: I don't have 5.8.5 handy, but http://static.cpantesters.org/distro/L/libwww-perl.html seems to suggest that it still passes down to 5.4.

As an author, I have to debate setting a minimum version by default to cover the range of code constructs I usually use, versus explicitly checking each time to see what minimum perl meets the features I actually used.

The latter is best, but requires more effort and potentially whipsaws people. Maybe my code works fine on 5.8 and then in some release, I use "//" and then the minimum jumps to 5.10. Instead, by saying "5.10" I might be implicitly promising that I'm targeting that version and won't be changing it capriciously.

I'm pretty open to a patch or a request if I can change a minimum without having to change how the code is written, but also I don't have a problem with authors targeting any minimum that makes their lives easier.

I spoke to Sebastian Riedel for you, and he said he'd be happy to take a test patch that makes it clear the contract with the user is to export the *5.10.1+* version of the given/when and ~~ semantics by failing on 5.10.0 so that nobody else comes to the same misunderstanding you did.

If you want pre-5.10.1 support you can use Catalyst, Dancer or Web::Simple, all of which still support 5.8.

On the other hand, LWP now requires 5.8.8 and *I* have filed a ticket querying this since so far as I can tell it should still work fine on 5.8.5 - if you'd be interested in doing testing for that I'd love the help.

-- mst

> you're complaining that authors whose work you get to use for free prefer a newer Perl than you do

No, I'm not. I'm saying that these people don't actually need that newer Perl. If they want to use newer features, or their tests break on an older Perl, they're welcome to go for it. But why make working code usable by less people by putting "use $VERSION" at the top? Other than for feature bundles, my philosophy is just to let people try the code on whatever version they want. If it breaks, the author has no obligation to fix the problems.

I expressed myself poorly. I meant that almost none of my code had broken with newer Perls. I can think of two things off the top of my head: (1) testing for the existence of various *FOO{THING} without creating them in the process (e.g. "defined %foo" got deprecated and *FOO{SCALAR} is finicky); (2) changes in the way B::GV::STASH() behaves in 5.10. I wish this stuff had changed less, but it would be too much to expect of the porters to keep finicky and undocumented things like this constant.

> If you can give me the rt.cpan.org ticket numbers for the reports you filed explaining that they work fine I can make sure those are chased up and the minimums changed in the next release.

Seriously? I thought about putting in a ticket for Mojolicious (it claims to require 5.10.1, but is fine on 5.10.0), but assumed it would just be instantly rejected. I'd be happy to do so if I thought it had some chance of being applied.