3 ms·

> backwards compatible bug fixes What even is a 'backwards compatible bug fix'? Unless it's performance, isn't a bug-fix by definition not going to be backward

> backwards compatible bug fixes What even is a 'backwards compatible bug fix'? Unless it's performance, isn't a bug-fix by definition not going to be backwards compatible?

Sharlin 4y ago
Any bugfix could be seen as backwards incompatible in the strict sense "somewhere, someone might actually depend on this buggy behavior", yes. That’s not a particularly good definition of backwards incompatibility when it comes to bugfixes, however. A more reasonable definition is "requires changes to downstream code" as in the bug cannot be fixed without changing public API as well. That said, sometimes there definitely exist bugs that a lot of users factually rely on, and changing such behaviors should not be done in patch releases.
lostcolony 4y ago
Which is why you provide patch notes, and why the more conservative consumers won't even auto-accept patch updates. The point is that a bug fix that doesn't change the API, and which only changes behavior to match intent and documentation, is something that requires minimal testing by the user. I.e., "fixed possible race condition where..." is a patch. It may be that a consumer relied on a particular bug when developing, yes, and that fixing it now 'breaks' their application, but that's a definite minority, and why you communicate out the fixes (and for auto-adopting patch releases, you ideally still have automatic tests to validate).
jjav 4y ago
> What even is a 'backwards compatible bug fix'? Unless it's performance, isn't a bug-fix by definition not going to be backwards compatible? It's a fix that makes the code work as documented, which it didn't do before, ergo had a bug. To pick a random example, the man page for strlen on Linux reads: "The strlen() function calculates the length of the string s, excluding the terminating null byte ('\0')." If it behaves differently (let's say it counts the terminating null) then strlen has a bug. The fix to that can go into a patch release because it simply fixes the interface to work as documented. You could go down a rathole of saying well maybe someone depends on the broken functionality. Sure, but that's not what the documented contract was. The documented functionality is the contract the API needs to meet.
- chrisseaton 4y ago
  That's too-specific an example. Often the bug is a corner case which wasn't considered, so that the documentation didn't say what was happening, and people were implying on the old relying behaviour.

> backwards compatible bug fixes What even is a 'backwards compatible bug fix'? Unless it's performance, isn't a bug-fix by definition not going to be backwards compatible?

Sharlin 4y ago

Any bugfix could be seen as backwards incompatible in the strict sense "somewhere, someone might actually depend on this buggy behavior", yes. That’s not a particularly good definition of backwards incompatibility when it comes to bugfixes, however. A more reasonable definition is "requires changes to downstream code" as in the bug cannot be fixed without changing public API as well. That said, sometimes there definitely exist bugs that a lot of users factually rely on, and changing such behaviors should not be done in patch releases.

lostcolony 4y ago

Which is why you provide patch notes, and why the more conservative consumers won't even auto-accept patch updates. The point is that a bug fix that doesn't change the API, and which only changes behavior to match intent and documentation, is something that requires minimal testing by the user. I.e., "fixed possible race condition where..." is a patch. It may be that a consumer relied on a particular bug when developing, yes, and that fixing it now 'breaks' their application, but that's a definite minority, and why you communicate out the fixes (and for auto-adopting patch releases, you ideally still have automatic tests to validate).

jjav 4y ago

> What even is a 'backwards compatible bug fix'? Unless it's performance, isn't a bug-fix by definition not going to be backwards compatible? It's a fix that makes the code work as documented, which it didn't do before, ergo had a bug. To pick a random example, the man page for strlen on Linux reads: "The strlen() function calculates the length of the string s, excluding the terminating null byte ('\0')." If it behaves differently (let's say it counts the terminating null) then strlen has a bug. The fix to that can go into a patch release because it simply fixes the interface to work as documented. You could go down a rathole of saying well maybe someone depends on the broken functionality. Sure, but that's not what the documented contract was. The documented functionality is the contract the API needs to meet.

chrisseaton 4y ago
That's too-specific an example. Often the bug is a corner case which wasn't considered, so that the documentation didn't say what was happening, and people were implying on the old relying behaviour.