But it is bad maintenance practice.

Upgrading to a new dependency without testing code with the new dependency is a worse maintenance practice.

Upgrading to a new dependency without testing code with the new dependency is a worse maintenance practice.

Agreed, but.

Running into trees is bad driving practice, so we put seatbelts and crumple zones and roll cages in cars (or do safety recalls) instead of putting a small sticker inside the glovebox that says "PLEASE DO NOT RUN INTO TREES AS YOU WILL GET HURT", or "CAR WILL ACCELERATE UNCONTROLLABLY IF FLOORMATS ARE LOOSE".

I think it's reasonable and responsible to consider the possibility of, and avoid, potentially dangerous situations, not blame the person in trouble: anti-lock brakes instead of blame-the-driver systems. Designing anti-lock brakes took time and effort, and most of the time they're unnecessary. But if they are, they make a big difference.

So I personally feel like I'm responsible for making this kind of difference when I can. Yes, programmers are supposed to be smart. But they are also sometimes tired, in a hurry, or a little careless - and sometimes, for whatever reason, they're not smart either. I think it's good practice to do a little extra myself so that if something dumb does happen, the damage is minimized, or even prevented.

Upgrading to a new dependency without testing code with the new dependency is a worse maintenance practice.

Agreed, but. To talk about "safety belts" from a different perspective:

Running into trees is bad driving practice, so manufacturers (after being forced to do so, interestingly enough) put seatbelts and crumple zones and roll cages in cars (or do safety recalls) instead of putting a small sticker inside the glovebox that says "PLEASE DO NOT RUN INTO TREES AS YOU WILL GET HURT", or "CAR WILL ACCELERATE UNCONTROLLABLY IF FLOORMATS ARE LOOSE" and saying "okay, job done". We buy the car and have to get used to how all the safety stuff works.

We do not, however, expect the car to end up with antilock brakes because we took it in for an oil change! If there was a service bulletin or a recall that required something like this, sure, we'd want it. But we'd be pretty upset if someone hadn't very carefully explained that the car was going to drive differently - because not making sure of this could cause an accident, and the driver would probably feel that the service folks had not done their job if there was one.

Back to software: I think it's reasonable and responsible to consider the possibility of, and avoid, potentially dangerous situations, not blame the person in trouble. Designing anti-lock brakes took time and effort, and most of the time they're unnecessary. But if they are, they make a big difference.

Yes, programmers are supposed to be smart. But they are also sometimes tired, in a hurry, or a little careless - and sometimes, for whatever reason, they're not smart either. I think it's good practice to do a little extra myself so that if something dumb does happen, the damage is minimized, or even prevented.

I feel like I'm responsible for making this kind of difference when I can.

Let me explain another way.

There are six and a half billion people in the world, plus or minus a few million.

Of those six and a half billion people, a few million have perhaps written some Perl 5 code. That leaves six and a half billion people who might someday need to write some Perl 5.

Perl 5 can perfectly well detect typos and warn of ambiguous or dangerous or useless constructs that novice programmers are going to make all of the time because they don't know Perl very well, but Perl 5 by default is for darn sure not going to help them because a couple of Perl experts who've used Perl for a decade and a half (if not more) would have to figure out that something may have changed in a new version of Perl 5 and perform some combination of updating their existing code, testing their existing code with the new version, or not blindly upgrading to the new version and wow, what a horrible burden to put on experts, especially experts who themselves have made changes to Perl 5 itself.

Fortunately, we live in a world where making little improvements which could help billions of people from making mistakes and to recover from those mistakes more easily is less important than teaching those Perl experts how to run awk or sed over a handful of programs to insert the cryptic message no strict; at the top.

Warn people about changes, certainly. Announce deprecations. Yet don't tell me that the people using software written and distributed and modifiable and redistributable with liberty preserved should be able to hold improvements hostage in the name of "But I can't test myyyyyyyyy code!"