Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

SemVer has significant benefit for package manager world. Many argue that why don’t you just read a changelog, but that is not the point. Package manager should know whether it can update some dependency to later version safely, without some guy always manually hardcoding the suitable version. It is everywhere. In Arch Linux, Debian, Pip and Cargo. They all rely on versions which itself should describe the impact of the change. If there is no standard, then it is always risky to update. On Debian it means manually testing every package. In Arch you accept the risk. If everyone would follow version schema, then you could trust the number in most of the cases.

My original message was a bit joke which some missed, but SemVer has a place and need.

> All software is continually developed, every release contains both new features and bug fixes, which violates semver.

Combination of them is not violation. Overall impact of the change should be described with the correct increment. It does not matter how do you categorise the content of the change.



It's often a change in interface. If you build from source, old code simply won't compile with new incompatible interface, and won't get to the testing stage.


The impact comes from the dependencies you are using. Depending how the software is made, it can be noticed early on build time. But it can also be noticed just on runtime, e.g. dynamic libraries, which is hopefully noticed on testing stage.

However, how it impacts downstream, the dependents of your software, cannot be tested. You can only inform about it. For people, with changelog. For automated systems, with version number. But if you do not follow systematic version numbering, you fail to inform automatic systems. They update to the later version of you software and dependents will break.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: