3 ms·

People don't understand how their code can mess up others in unexpected ways. A few weeks ago my youtube just stopped working. Turns out, a change made to the a

People don't understand how their code can mess up others in unexpected ways. A few weeks ago my youtube just stopped working. Turns out, a change made to the apollo-graphql extension caused window.process to be readonly and youtube's code was not expecting that: https://github.com/apollographql/apollo-client-devtools/issues/455 https://github.com/apollographql/apollo-client-devtools/issu... I know this isn't a dependency issue, but it's a great example of why things like semver don't work perfectly in practice. It's hard to figure out what the effects of your code really are in the end. You might assume a change is minor when it really is major. I wish programming languages could figure out what the version change should be for a given code change.

dec0dedab0de 5y ago
Sure, but that's just a bug in an application introduced by accident, and fixed when they found out about it. That is going to happen no matter what. The same thing goes for libraries. That is the best part of this tool, since they control the library and all the clients they can automatically run their tests across everything. Which would help you catch more of these types of problems, but it will never be perfect. My point is that if a user of your library is failing after a change, you should treat that as a bug in the library. Backwards incompatible changes should only be on purpose, and only when absolutely necessary. Of course, it's only their own code they're affecting here, so it doesn't really matter as much as a library for users you don't know. Plus it is a pretty cool solution, I just don't think it should be necessary.
jesseryoung 5y ago
"Don't change the function signature" and semver are things that are absolutely hammered into devs who work on library code. I'd be hard pressed to find somebody even tangentially involved in software development who doesn't understand this. Semver doesn't cover changes in behavior. What a "breaking change" is when it comes to behavior changes is up to the person who implemented it.
- jnxx 5y ago
  >Semver doesn't cover changes in behavior. It does: https://semver.org/ https://semver.org/ "Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive." If the API changes semantics between different releases, it is a breaking change. It does not matter whether the types in the function signature is identical. If printReport(int invoice_number) prints a report in version 1.0, and deletes the database or launches nuclear weapons in version 1.1, it does not follow semantic versioning. But the core problem with semantic versioning is that it somehow legitimizes to make breaking changes all the time. It is not OK to beat somebody up in a bar. It is also not OK to tell somebody that he is going to be beaten up, and then beat him up. Now, semantic versioning holds the idea that it is OK to make breaking changes, if only you tell people before. And this is a lousy idea. Breaking changes break other people's code, especially if they use it in deep graphs of dependencies. And they can't necessarily do anything about it, because they might have two dependencies which are depending on your library, only that the first one now requires version 2.0 at least, while the second one will not work with anything newer than version 1.99.17. And thus the whole project is broken. Actually, requiring the new version 2.0 in the first dependency is a breaking change, too, because it breaks backwards-compatibility. And this is something which the Python devs just did not comprehend - that this kind of breakage trickles up dependency graphs and makes it extremely difficult for users with a limited budget to make upgrades, even if most of their features are highly desired.

dec0dedab0de 5y ago

Sure, but that's just a bug in an application introduced by accident, and fixed when they found out about it. That is going to happen no matter what. The same thing goes for libraries. That is the best part of this tool, since they control the library and all the clients they can automatically run their tests across everything. Which would help you catch more of these types of problems, but it will never be perfect. My point is that if a user of your library is failing after a change, you should treat that as a bug in the library. Backwards incompatible changes should only be on purpose, and only when absolutely necessary. Of course, it's only their own code they're affecting here, so it doesn't really matter as much as a library for users you don't know. Plus it is a pretty cool solution, I just don't think it should be necessary.

jesseryoung 5y ago

"Don't change the function signature" and semver are things that are absolutely hammered into devs who work on library code. I'd be hard pressed to find somebody even tangentially involved in software development who doesn't understand this. Semver doesn't cover changes in behavior. What a "breaking change" is when it comes to behavior changes is up to the person who implemented it.

jnxx 5y ago
>Semver doesn't cover changes in behavior. It does: https://semver.org/ https://semver.org/ "Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it SHOULD be precise and comprehensive." If the API changes semantics between different releases, it is a breaking change. It does not matter whether the types in the function signature is identical. If printReport(int invoice_number) prints a report in version 1.0, and deletes the database or launches nuclear weapons in version 1.1, it does not follow semantic versioning. But the core problem with semantic versioning is that it somehow legitimizes to make breaking changes all the time. It is not OK to beat somebody up in a bar. It is also not OK to tell somebody that he is going to be beaten up, and then beat him up. Now, semantic versioning holds the idea that it is OK to make breaking changes, if only you tell people before. And this is a lousy idea. Breaking changes break other people's code, especially if they use it in deep graphs of dependencies. And they can't necessarily do anything about it, because they might have two dependencies which are depending on your library, only that the first one now requires version 2.0 at least, while the second one will not work with anything newer than version 1.99.17. And thus the whole project is broken. Actually, requiring the new version 2.0 in the first dependency is a breaking change, too, because it breaks backwards-compatibility. And this is something which the Python devs just did not comprehend - that this kind of breakage trickles up dependency graphs and makes it extremely difficult for users with a limited budget to make upgrades, even if most of their features are highly desired.