4 ms·

It's a convention that cannot really be enforced by compiler or any tooling, it ultimately relies on humans following it, hence it will always be broken in some

It's a convention that cannot really be enforced by compiler or any tooling, it ultimately relies on humans following it, hence it will always be broken in some way for some users.

jsjohnst 7y ago
Sure, I’ll give that it’s a very hard problem to enforce (not impossible, but very hard with virtually all current language implementations). That doesn’t negate the benefits of having a social contract (what semantic versioning is) that says you strive to do the right thing, even if you sometimes fail.
- lugg 7y ago
  What benefits? Everyone else just maintains backwards compatibility. Why are you so such a snowflake? Nobody asked you to "improve" you library by breaking it.
  - beatgammit 7y ago
    Sometimes you need to break backwards compatibility to fix a security issue or implement a new, desired feature. Most often the breakage is small, but it's still nice to know as a library user when the build may break. Yes, try to avoid breaking backwards compatibility, but have some mechanism to handle the rare case when you do need to break guarantees. Most of the libraries I use that follow semver rarely break backwards compatibility, and it's still helpful to use semver to note bugfixes vs new features. New features can be a liability and introduce bugs, bugfixes are frequently quite safe, so it lets me know how much effort I should expect to spend testing when pulling in a new version. When I'm close to a release, I'll avoid new feature releases, but probably pull in bugfix releases.
  - jsjohnst 7y ago
    Your reply feels unnecessarily confrontational / aggressive, but I’ll respond anyway. > Everyone else just maintains backwards compatibility. Name one piece of software of substantive size and with a history longer than a couple years, which never had a backwards compatibility break ever? Just in case you can name one, then name two instead. Contrary to your statement, 99.99999% of software has a backwards incompatible change at some point. What’s a good way to indicate that to your end users? Semantic versioning. > Nobody asked you to "improve" you library by breaking it. So if a major bug is found after release, one should never fix it? Fixing a bug could easily lead to a backwards incompatible break, if nothing else because someone was depending on that buggy behavior.
    - lugg 7y ago
      Asking me to name perfect records is impossible and unnecessary. You do not have to maintain backwards compatibility forever in all cases. My only argument is that it being the default approach to changing software isbwhat offers the best results without the added cost of semantic versioning and all the treeshaking failures that comes along with it. Linux userland APIs, C/C++, WordPress, Clojure are all pretty successful software that maintain backwards compatibility as some form of priority and commitment with varying degrees of success. None of which get much lament for doing so compared to say nodejs/JS/npm which are routinely the laughing stock of the industry for their lack of platform stability. > Bug fix Your point about these is pretty funny because these breaking changes are specifically allowed by semver as minor patches. Which was kind of my original point here it's a flawed spec that offers no real safety at great cost.
cmrx64 7y ago
https://github.com/rust-dev-tools/rust-semverver https://github.com/rust-dev-tools/rust-semverver tries!
fluffything 7y ago
Actually, you are wrong in that semver cannot be enforced by tooling. Rust has tooling to automatically enforce semver. For example, this tool: https://github.com/rust-dev-tools/rust-semverver https://github.com/rust-dev-tools/rust-semverver Once you modify a Rust library, it downloads the last released version, compiles it and extracts its AST, and compares it with the AST of the current version. The diff of the two ASTs tells you what the changes are, and there is a Rust book that documents which changes are semver breaking and which aren't. So if you only add a new function to your crate, the tool says that you can bump the semver patch version or minor version, but if you change the name of a public API, the tool requires you to make a new major semver release. Setting this tool in CI is dead easy, and will make your CI fail if a PR changes the API of your crate without properly updating its semver version.
- lugg 7y ago
  That sounds super interesting I didn't know rust crates were managed like this. The question in my mind is where does semver come into this? Why do you need three arbitrary and meaningless numbers when a commit hash, branch, or tag would suffice.

It's a convention that cannot really be enforced by compiler or any tooling, it ultimately relies on humans following it, hence it will always be broken in some way for some users.

jsjohnst 7y ago

Sure, I’ll give that it’s a very hard problem to enforce (not impossible, but very hard with virtually all current language implementations). That doesn’t negate the benefits of having a social contract (what semantic versioning is) that says you strive to do the right thing, even if you sometimes fail.

lugg 7y ago
What benefits? Everyone else just maintains backwards compatibility. Why are you so such a snowflake? Nobody asked you to "improve" you library by breaking it.
- beatgammit 7y ago
  Sometimes you need to break backwards compatibility to fix a security issue or implement a new, desired feature. Most often the breakage is small, but it's still nice to know as a library user when the build may break. Yes, try to avoid breaking backwards compatibility, but have some mechanism to handle the rare case when you do need to break guarantees. Most of the libraries I use that follow semver rarely break backwards compatibility, and it's still helpful to use semver to note bugfixes vs new features. New features can be a liability and introduce bugs, bugfixes are frequently quite safe, so it lets me know how much effort I should expect to spend testing when pulling in a new version. When I'm close to a release, I'll avoid new feature releases, but probably pull in bugfix releases.
- jsjohnst 7y ago
  Your reply feels unnecessarily confrontational / aggressive, but I’ll respond anyway. > Everyone else just maintains backwards compatibility. Name one piece of software of substantive size and with a history longer than a couple years, which never had a backwards compatibility break ever? Just in case you can name one, then name two instead. Contrary to your statement, 99.99999% of software has a backwards incompatible change at some point. What’s a good way to indicate that to your end users? Semantic versioning. > Nobody asked you to "improve" you library by breaking it. So if a major bug is found after release, one should never fix it? Fixing a bug could easily lead to a backwards incompatible break, if nothing else because someone was depending on that buggy behavior.
  - lugg 7y ago
    Asking me to name perfect records is impossible and unnecessary. You do not have to maintain backwards compatibility forever in all cases. My only argument is that it being the default approach to changing software isbwhat offers the best results without the added cost of semantic versioning and all the treeshaking failures that comes along with it. Linux userland APIs, C/C++, WordPress, Clojure are all pretty successful software that maintain backwards compatibility as some form of priority and commitment with varying degrees of success. None of which get much lament for doing so compared to say nodejs/JS/npm which are routinely the laughing stock of the industry for their lack of platform stability. > Bug fix Your point about these is pretty funny because these breaking changes are specifically allowed by semver as minor patches. Which was kind of my original point here it's a flawed spec that offers no real safety at great cost.

cmrx64 7y ago

https://github.com/rust-dev-tools/rust-semverver https://github.com/rust-dev-tools/rust-semverver tries!

fluffything 7y ago

Actually, you are wrong in that semver cannot be enforced by tooling. Rust has tooling to automatically enforce semver. For example, this tool: https://github.com/rust-dev-tools/rust-semverver https://github.com/rust-dev-tools/rust-semverver Once you modify a Rust library, it downloads the last released version, compiles it and extracts its AST, and compares it with the AST of the current version. The diff of the two ASTs tells you what the changes are, and there is a Rust book that documents which changes are semver breaking and which aren't. So if you only add a new function to your crate, the tool says that you can bump the semver patch version or minor version, but if you change the name of a public API, the tool requires you to make a new major semver release. Setting this tool in CI is dead easy, and will make your CI fail if a PR changes the API of your crate without properly updating its semver version.

lugg 7y ago
That sounds super interesting I didn't know rust crates were managed like this. The question in my mind is where does semver come into this? Why do you need three arbitrary and meaningless numbers when a commit hash, branch, or tag would suffice.