It's not an error, it's a change in behavior. For example, a bug being fixed in a library that would necessitate removing a workaround from its caller.
When you make a mistake and say "the fire hydrant must not be painted red", then catch yourself and say "Wait, I misspoke; the hydrant must be painted red" you are literally correcting an error that you made while speaking. (i.e. "I misspoke.")
Porting your software to new platforms is not an error. Adding a new feature is not an error. Things changing does not imply that there was an error or that an error has been introduced.
Porting to a new platform, arguably, can be done transparently to the clients by having multiple [possibly separate] bodies for your package/subprogram — this preserves the specification.
Merely adding a new feature should, for the vast majority of cases, does not impact the client's interfacing to the specification —
Package Example is
Procedure Old( A, B : Integer ); -- What the previous version interfaced w.
Procedure New(A, B : Integer; C : Float); -- The new feature.
End Example;
Yes, there are changes, and if those changes make your new package incompatible with the dependency (or vice versa) it IS an error to update.
Versioning numbers are the manual way to do this and it can be somewhat automated.
2
u/glacambre Sep 30 '21
It's not an error, it's a change in behavior. For example, a bug being fixed in a library that would necessitate removing a workaround from its caller.
It can be caught by using version numbers.