3 ms·

> who cares if there's breaking changes. Semantic version is mostly bullshit anyway. You can never guarantee that a non-breaking change is non-breaking for ev

> who cares if there's breaking changes. Semantic version is mostly bullshit anyway. You can never guarantee that a non-breaking change is non-breaking for every single one of your users. Anecdote: Just yesterday our entire CI process was taken down due to a bump in the AWS ebcli package from 3.20.0 -> 3.20.1. This should have been a non-breaking change, but instead resulted in an entire days worth of release management being grinded to a halt. Pin your versions. Test all upgrades.

lucideer 5y ago
An anecdote about one time the system failed (yes we're human, nothing is ever applied perfectly), followed by the very simple suggestion that we instead all comprehensively and completely test every patch release of every dependency in our chain (we'd all like to but see above about humans and perfection). Semver brings net benefit for the times when it is applied correctly. For the rest, we do our best to test as much as we can.
- rubyist5eva 5y ago
  The advice is to not just willy-nilly just pull in the latest patch releases just because it's "supposed" to work. Regularly testing and updgrading at _least_ your core dependencies should be part of the day job of any competent team. If you have too many dependencies to have capacity to do this on an ongoing basis - maybe you just have too many dependencies. Excuses don't make the problem go away. Just assuming you can upgrade something from 3.20.1 over 3.20.0 because it just happened to release 9 hours ago is a recipe for disaster. Pin your version to 3.20.0 - regularly review your dependencies, upgrade and test - THEN roll it out system wide. Don't just assume something is going to work and roll it out to everyone without checking because some arbitrary versioning scheme says it should. Be thoughtful. Methodical. Consistent.
wolrah 5y ago
> Semantic version is mostly bullshit anyway. You can never guarantee that a non-breaking change is non-breaking for every single one of your users. You are misunderstanding the scope of SemVer. It's purely about intentional changes to public interfaces. It should go without saying that no versioning scheme can ever hope to indicate whether or not new bugs have been introduced or uncovered that impact your consumer of said interface, nor can it possibly anticipate potential bugs in consumers that could be triggered by any changes that result in valid but previously unseen data being returned. It also doesn't say anything about the update process itself. If an update fails in such a way that your consumer can't use the interface that has nothing to do with the version number. No one reasonable has ever claimed that SemVer could allow you to just YOLO your updates without testing. When implemented properly it provides a comfort level for updates that should give you an idea of how closely you should look at the changes being made and how they might impact whatever you have consuming that interface.

lucideer 5y ago

An anecdote about one time the system failed (yes we're human, nothing is ever applied perfectly), followed by the very simple suggestion that we instead all comprehensively and completely test every patch release of every dependency in our chain (we'd all like to but see above about humans and perfection). Semver brings net benefit for the times when it is applied correctly. For the rest, we do our best to test as much as we can.

rubyist5eva 5y ago
The advice is to not just willy-nilly just pull in the latest patch releases just because it's "supposed" to work. Regularly testing and updgrading at _least_ your core dependencies should be part of the day job of any competent team. If you have too many dependencies to have capacity to do this on an ongoing basis - maybe you just have too many dependencies. Excuses don't make the problem go away. Just assuming you can upgrade something from 3.20.1 over 3.20.0 because it just happened to release 9 hours ago is a recipe for disaster. Pin your version to 3.20.0 - regularly review your dependencies, upgrade and test - THEN roll it out system wide. Don't just assume something is going to work and roll it out to everyone without checking because some arbitrary versioning scheme says it should. Be thoughtful. Methodical. Consistent.

wolrah 5y ago

> Semantic version is mostly bullshit anyway. You can never guarantee that a non-breaking change is non-breaking for every single one of your users. You are misunderstanding the scope of SemVer. It's purely about intentional changes to public interfaces. It should go without saying that no versioning scheme can ever hope to indicate whether or not new bugs have been introduced or uncovered that impact your consumer of said interface, nor can it possibly anticipate potential bugs in consumers that could be triggered by any changes that result in valid but previously unseen data being returned. It also doesn't say anything about the update process itself. If an update fails in such a way that your consumer can't use the interface that has nothing to do with the version number. No one reasonable has ever claimed that SemVer could allow you to just YOLO your updates without testing. When implemented properly it provides a comfort level for updates that should give you an idea of how closely you should look at the changes being made and how they might impact whatever you have consuming that interface.