3 ms·

> If you want to print deprecation warnings for something, the system administrators of the world will thank you if you make it not the default behavior. That w

> If you want to print deprecation warnings for something, the system administrators of the world will thank you if you make it not the default behavior. That way people who actually care can check when they want to (or run in checking mode all the time), but you won't cause pain for others. And so that they can have an excuse to say they have not been informed of the deprecation and call you names. Seriously, this basically amounts to never deprecating anything at all.

jeroenhd 3y ago
As long as those deprecation errors a are accompanied with an upgrade guide detailing the deprecations, you can't be blamed for anything. I'm sure people will upgrade willy-nilly and still call you names, but at least they've had plenty of warning. Besides, if your program doesn't work on their test environment after updating because it needs some extra config to enable legacy behaviour, their update process will have to slow down (alter config and retry) but no serious downtime will occur.
- 7steps2much 3y ago
  > if your program doesn't work on their test environment Bold of you to assume they have one of those! Personally I assume they will break production, then call you names because of it.
  - jeroenhd 3y ago
    I realize that's a realistic problem. How you deal with people like that really depends on your environment. For open source software: too bad. The AS IS part of the license should cover expectations well. For commercial software: depends on the contract, really. If the contract hasn't specified anything, an upgrade document will work fine in many cases. For enterprise software: your customers won't update your software anyway. I'd go with warnings just to be safe. Maybe do it in three stages, first warnings, then severe warnings, then errors. If you really want to grab attention for your warnings, prefix them with <<COMPLIANCY RISK ALERT>> and you'll be sure to get them to read the upgrade guide!
bin_bash 3y ago
> this basically amounts to never deprecating anything at all yeah, though from the perspective of a sysadmin I suspect this is what they would prefer
- deredede 3y ago
  To be fair, I suspect many developers would also prefer their dependencies never deprecating anything either.
  - izacus 3y ago
    Yep, and they'd also prefer to never maintain anything ever and constantly change their own APIs on a daily basis.
- hotpotamus 3y ago
  I was about to quote the same thing and say "yes, please". If the plan is to replace what is being deprecated with something truly better, then by all means, let's do it. But if it's more about resume padding by re-writing in the latest hot language, then I'd just as soon skip it. Of course, telling the difference is never so simple.
  - JdeBP 3y ago
    The reason that this has come up again was a little more complex. It wasn't resume padding, and it wasn't writing in an alternative language. It was about deprecating and then removing long standing Unix command names, with histories back at least as far as the middle/early 1980s, simply because they aren't now in the Single Unix Specification. They were in the SVID.

jeroenhd 3y ago

As long as those deprecation errors a are accompanied with an upgrade guide detailing the deprecations, you can't be blamed for anything. I'm sure people will upgrade willy-nilly and still call you names, but at least they've had plenty of warning. Besides, if your program doesn't work on their test environment after updating because it needs some extra config to enable legacy behaviour, their update process will have to slow down (alter config and retry) but no serious downtime will occur.

7steps2much 3y ago
> if your program doesn't work on their test environment Bold of you to assume they have one of those! Personally I assume they will break production, then call you names because of it.
- jeroenhd 3y ago
  I realize that's a realistic problem. How you deal with people like that really depends on your environment. For open source software: too bad. The AS IS part of the license should cover expectations well. For commercial software: depends on the contract, really. If the contract hasn't specified anything, an upgrade document will work fine in many cases. For enterprise software: your customers won't update your software anyway. I'd go with warnings just to be safe. Maybe do it in three stages, first warnings, then severe warnings, then errors. If you really want to grab attention for your warnings, prefix them with <<COMPLIANCY RISK ALERT>> and you'll be sure to get them to read the upgrade guide!

bin_bash 3y ago

> this basically amounts to never deprecating anything at all yeah, though from the perspective of a sysadmin I suspect this is what they would prefer

deredede 3y ago
To be fair, I suspect many developers would also prefer their dependencies never deprecating anything either.
- izacus 3y ago
  Yep, and they'd also prefer to never maintain anything ever and constantly change their own APIs on a daily basis.
hotpotamus 3y ago
I was about to quote the same thing and say "yes, please". If the plan is to replace what is being deprecated with something truly better, then by all means, let's do it. But if it's more about resume padding by re-writing in the latest hot language, then I'd just as soon skip it. Of course, telling the difference is never so simple.
- JdeBP 3y ago
  The reason that this has come up again was a little more complex. It wasn't resume padding, and it wasn't writing in an alternative language. It was about deprecating and then removing long standing Unix command names, with histories back at least as far as the middle/early 1980s, simply because they aren't now in the Single Unix Specification. They were in the SVID.