3 ms·

Not every project follows semver. Just because there are numbers with periods interspersed doesn't mean it's semantic versioning. People have been throwing nu

Not every project follows semver. Just because there are numbers with periods interspersed doesn't mean it's semantic versioning. People have been throwing numbers together to communicate something about what it is for a long time now, long before semantic versioning was formalized.

cogman10 5y ago
Which is exactly the point I'm making. Semver only really works if everyone, or most everyone, is following it. There are a lot of build tools that make that assumption. (cargo, npm, gradle, pip, for example). Without that, you end up needing to have very deep understandings of your dependencies and their subdependencies. Otherwise, it's impossible to know what will happen when you update something.
- kbenson 5y ago
  I get more what you're trying to say now. To some degree, some people are definitely failing to adhere to semver when they're part of a larger ecosystem that needs it, like the ones you mentioned. Regardless of what versioning a module uses internally for development, they should be exposing a good semver compatible version to the tooling that uses them that expects it, but they often fail in this. There is, alternatively, likely some assumption at this point in end users that some random project on github or elsewhere might be following semver even if they haven't stated as much, and without a stated intention to follow semver by the project and showing that they are willing to do so that means little and is a poor assumption. That's not necessarily applicable to your original point though.
- azernik 5y ago
  It doesn't need everyone to follow it; it just needs library maintainers to declare when they do follow it, actually mean it when they do, and check their own dependencies for breaking changes. ie a library that declares it uses semver should create an abstraction barrier around all of its dependencies, such that the user should only need to care about declared breakages in their direct dependencies.
- volta83 5y ago
  This is funny because everybody makes mistakes , so of course people fail at semver. However, if you are the maintainer of a popular cargo package, and make a mistake, people _will let you know_. Because a lot of people in the Rust ecosystem expect versions to follow semver. Crates that fail to adhere stop being used, get bad rep, people fork them, and keep them stable, making them loose users. Rust actually has a tool called rust-semverver that does an AST to AST diff of the current version of a crate that you want to release, with the latest release, and suggests how to increment the version. It can list all API changes, and it will tell you which changes are minor, major, or patch. You can use it in your deployment workflow on CI to, e.g., deploy a new version of a crate only if, the changes follow the version change that was specified. Such that, e.g., if you bump your 2.0.0 crate to 2.1.0 but your crate has an API breaking change, the tool and CI fails telling you that you need to change the version to 3.0.0 because of these changes.
  - judofyr 5y ago
    Well, it seems like most of the critical packages in the Rust ecosystem are at 0.x so I’m not sure how much this is being done in practice.

cogman10 5y ago

Which is exactly the point I'm making. Semver only really works if everyone, or most everyone, is following it. There are a lot of build tools that make that assumption. (cargo, npm, gradle, pip, for example). Without that, you end up needing to have very deep understandings of your dependencies and their subdependencies. Otherwise, it's impossible to know what will happen when you update something.

kbenson 5y ago
I get more what you're trying to say now. To some degree, some people are definitely failing to adhere to semver when they're part of a larger ecosystem that needs it, like the ones you mentioned. Regardless of what versioning a module uses internally for development, they should be exposing a good semver compatible version to the tooling that uses them that expects it, but they often fail in this. There is, alternatively, likely some assumption at this point in end users that some random project on github or elsewhere might be following semver even if they haven't stated as much, and without a stated intention to follow semver by the project and showing that they are willing to do so that means little and is a poor assumption. That's not necessarily applicable to your original point though.
azernik 5y ago
It doesn't need everyone to follow it; it just needs library maintainers to declare when they do follow it, actually mean it when they do, and check their own dependencies for breaking changes. ie a library that declares it uses semver should create an abstraction barrier around all of its dependencies, such that the user should only need to care about declared breakages in their direct dependencies.
volta83 5y ago
This is funny because everybody makes mistakes , so of course people fail at semver. However, if you are the maintainer of a popular cargo package, and make a mistake, people _will let you know_. Because a lot of people in the Rust ecosystem expect versions to follow semver. Crates that fail to adhere stop being used, get bad rep, people fork them, and keep them stable, making them loose users. Rust actually has a tool called rust-semverver that does an AST to AST diff of the current version of a crate that you want to release, with the latest release, and suggests how to increment the version. It can list all API changes, and it will tell you which changes are minor, major, or patch. You can use it in your deployment workflow on CI to, e.g., deploy a new version of a crate only if, the changes follow the version change that was specified. Such that, e.g., if you bump your 2.0.0 crate to 2.1.0 but your crate has an API breaking change, the tool and CI fails telling you that you need to change the version to 3.0.0 because of these changes.
- judofyr 5y ago
  Well, it seems like most of the critical packages in the Rust ecosystem are at 0.x so I’m not sure how much this is being done in practice.