There is one school of software engineering which upgrades all warnings to be errors and thus fatal because "warning culture" leads complacency. Thus emitting a new warning as part of default behavior will break builds.
Yes. But if you do that, then you need to be willing to fix new warnings (or ignore them) when you update dependencies. After all, if an update adds a new warning about something dangerous you are doing in your code, but shouldn't be, wouldn't you like to know about it?
Breaking over new warnings seems crazy, but that can be one of the prices of stability. C, Perl, JavaScript and others have similar problems and come to their own solutions.
(For instance, C has warnings under the -W flags and you could enable them all at compile time with -Wall, but then people depended on the specific flags under that option so there's also -Wextra now.)
Stability means sometimes you stay still when there are good reasons to move, though there's always a balance. Perhaps a larger solution is needed (more prevalent version pinning, or an ASDF 4.0), but this may be a tempest in a teapot. We'll see how this particular issue shakes out.
tgbugs|4 years ago
thayne|4 years ago
jevoten|4 years ago
jbovlaste|4 years ago
(For instance, C has warnings under the -W flags and you could enable them all at compile time with -Wall, but then people depended on the specific flags under that option so there's also -Wextra now.)
Stability means sometimes you stay still when there are good reasons to move, though there's always a balance. Perhaps a larger solution is needed (more prevalent version pinning, or an ASDF 4.0), but this may be a tempest in a teapot. We'll see how this particular issue shakes out.
dathinab|4 years ago
its crazy, and supper harmful
sadly it's not that rare in e.g. C/C++ as far as I know