On Perl 5.6
There's been some discussion back and forth recently about perl version support, and especially perl 5.6 support.
Some people seem to be advocating for intentionally breaking support even when it isn't currently actively causing a problem, because forced obsolescence is a good and necessary thing.
To quote from twitter: "any remaining 5.6 users need to upgrade and anyone still on 5.6 needs to lose CPAN to grok that".
I ... don't think this position makes sense, on several levels.
Firstly, I think it's pretty likely that, at this point, anybody still using 5.6 is doing so because for whatever reason they actually can't upgrade. I can't see somebody doing it voluntarily, although, y'know, there's a whole universe of terrifying kinks out there, so it might be theoretically possible.
Secondly, it seems rather against the spirit of open source to say "actually, no, I'm not just going to say 'I officially don't support this', I'm going to explicitly and intentionally break it even though other than that it was working fine.
Adding a 'use 5.008;' line to a piece of code just because you think 5.6 should go away is basically tantamount to the hard-coded die() in AnyEvent stopping you from using it with IO::Async in certain configurations. It's ... just not how open source is done.
On the other hand, I absolutely don't want to suggest that everybody should be making the effort with every module they release to support perl 5.6. In fact, I absolutely don't think, in general, it's worth bothering. My projects always start with a 5.8.1 hard-coded minimum requirement, and I'm totally ok with that.
However.
If somebody removes that line, and tests it on 5.6, and confirms it works, I'm happy to take a patch that makes the removal part of the mainline sources.
Why should I stop somebody using a piece of code in a way that they've discovered works fine just because I didn't actually care whether it worked or not that far back?
Now, the usual response to this is "but now I have to care about 5.6 compatibility and I don't want to", which would be a reasonable response if true. But it turns out in practice that isn't actually true.
I don't make any particular effort to care about 5.6 even on dists of mine that currently work there. I don't gratuitously break it, i.e. I don't usually intentionally write something that isn't going to work and then immediately release that - but if I want a 5.8 only construct, I'll quite possibly use it and then ping the last person to care about 5.6 for this dist to supply a patch that then backports it.
So, ok, I make a slight effort. But really not much, because on a number of occasions I've accidentally broken 5.6 support because I wasn't paying attention. Nobody complained about this, they all understood that the contract was "I will let somebody who cares about it support 5.6 but I'm not taking any particular care myself". In fact, what they did was - they sent a patch that made 5.6 work again. Which I applied and released, because that was a two minute job.
For toolchain level code I try a bit harder, because for toolchain level code you should always try a bit harder not to break a case that was already working, because it really sucks when you end up with a broken toolchain because now reinstalling the working versions is non-trivial - I usually have to yell "I HAVE NO TOOLS BECAUSE I'VE DESTROYED MY TOOLS WITH MY TOOLS" at the monitor and then go for a smoke first when that happens.
But, on the whole, the way it goes is "I am not going to go out of my way to support 5.6, but if there are people willing to send patches to restore 5.6 compat any time it breaks, then I see no reason to stand in the way of their willingness to do so". Just because I don't care very much doesn't mean I feel the need to tell the people who do care about it they're wrong to do so (I also accept doc patches tweaking sentence structure from people who're even more sensitive to iffy grammar than I am :).
Plus, I think a precedent of "I am willing to apply patches even when they fix something I didn't particularly mind being broken" is a useful one to set - I've run into this repeatedly when trying to fatpack things, and users have usually accomodated me - and the counterarguments I've heard have been "well everybody should have a recent perl and a working compiler", which sounds really similar and just as unfair on people who don't have that choice.
The funny thing here is that the people working hard on fatpackability overlap quite strongly with the people who care about 5.6 - so if you tell them to go away, you're asking for a future where eventually you don't get to have cpanminus anymore and you can't fatpack apps using Moo - and I don't think I really want to live in that future.
But, really, that isn't the thing that I find a truly convincing argument.
What I find a truly convincing argument is: When the people sending me such patches go out of their way to make accepting their contributions easy to accept ... it would seem churlish of me to refuse.
There's more than one way to contribute to the perl community, after all.
-- mst, out.