2 ms·
Nobody reads these. It’s alert noise. If it broke every 10% of runs folks would notice. Brutal but there’s zero cost of ignoring the warning beforehand.
by baq 2y ago
Nobody reads these. It’s alert noise.
If it broke every 10% of runs folks would notice. Brutal but there’s zero cost of ignoring the warning beforehand.
- kalaksi 2y agoI wouldn't say it's zero cost. It's a risk with potential to cost you. So there's some kind expected value to that cost and the risk grows the longer you ignore the warning
- baq 2y agoI kind of agree - though I make a distinction between risk and cost in the same way you say 'potential cost' i.e. cost is realized risk. Until the risk materializes, you don't pay. The base scenario in this case is the classic thanksgiving turkey though - everything is fine until it isn't.
- SAI_Peregrinus 2y agoOften nobody even sees them. The software gets built by a CI system, there's no way for the CI system to alert on new warnings appearing, and nobody checks the logs. Maybe a staged process. Start with a warning as usual, to CYA. Nobody will care, but you can feel smug and say you told them. Then turn it into an error and add a flag that a user can set to turn that deprecation back into a warning. Setting the flag should be a trivial change, but since builds will fail it'll be noticeable. The build failure message should include the date the deprecated feature will be removed, a link to migration steps, and instructions on how to set the flag to allow builds to succeed. Then finally remove the feature. That would allow users a chance to schedule work to remove use of the deprecated feature.