[bryanlarsen]

This is sweet:

For example, if I have three packages:

   - uno depends on json 1.3.6
   - dos depends on json 1.4.12
   - tres depends on json 2.1.0

Cargo will use json 1.4.12 for uno and dos, and json 2.1.0 for tres.

Hopefully rust builds a culture that respects semantic versioning better than the Ruby & Node cultures do. That has to start at the top. There were several Rails 2.3.X releases with minor ABI incompatibilities. Truly respecting semver would have required these patch level updates to get a new major number.

[steveklabnik]

Note that this is a sliiiightly modified SemVer: in SemVer, these three things would conflict. It would be strict SemVer if uno depended on ~>1.3, and dos on ~>1.4.

We hypothesize that this difference works better for AOT compiled languages. And since it's pre-1.0, it's all good. This is the 'we'll watch this closely and adjust' from the email: it might not be okay.

[ionforce]

Why would uno not work on 1.4?

[steveklabnik]

When you declare an x.y.z dependency, tools that use SemVer (like Bundler, which is the biggest influence on Cargo) assume x.y.(>z). So, a 1.4.12 dependency says "Anything greater than 1.4.12, but less than 1.5.0."

When you declare an x.y dependency, tools that use SemVer assumes x.(>y). So, a 1.4 dependency says "Anything greater than 1.4.anything, but less than 2.anything.anything".

This is assuming the ~> operator, if it was =, it would ONLY be 1.14.2, which is even more restrictive.

The project _should_ work, which is why Cargo is using this modified version of ~>.

[Argorak]

Don't equate Rails with Ruby (some projects follow semver very closely).

Rails follows a shifted semver version, as documented here: https://github.com/rails/rails/blob/master/guides/source/mai...

Bumps from 4.x to 4.y might contain smaller breaking changes.

For a large project as Rails, I find that reasonable, otherwise, we'd be at Rails 20 by now, which also doesn't quite give a good sense of how the project evolved.

[bryanlarsen]

Rails, for better or worse, is the flagship project of Ruby, and shapes the Ruby culture quite strongly.

I would much prefer Rails 20 than the current situation. If you want to make a major marketing level move, introduce a codename or something. Separate marketing from semantics.

[awj]

MRI didn't follow semver up until recently, and even now it has some caveats about it.

Ruby as an ecosystem doesn't really care for semver. Some projects follow it anyways, which I can respect, but they aren't the norm.

[Argorak]

MRI picked its version scheme in the 90s, long before "semver" was a thing. That kind of version scheme wasn't unusual in that time. Problems due to legacy don't make a good argument.

The Ruby system cares for semver in general and it is propagated there a lot, but I agree: it certainly isn't uniform.

[matdes]

MRI still doesn't follow semver but core doesn't really give a crap.

[steveklabnik]

They claim "Semantic Versioning type" versioning, which is, of course, not SemVer, but I think what your parent was referring to.

https://www.ruby-lang.org/en/news/2013/12/21/ruby-version-po...

[mercurial]

What would be fantastic is if a Cargo repo could refuse a package which doesn't follow follow this policy (try to upload a new minor version with an incompatible ABI, get 400 Bad Request as a response). Of course, it won't save you from a change in semantics, but it would already be a good step forward.

[kibwen]

I'd be very curious to know if it's possible for an automated tool to perfectly detect ABI breakage.

[adrusi]

It would be impossible to do so perfectly for a turing complete language. You could get close by running the previous minor version's test suite against the new update, but that would essentially make the package repository into a continuous integration server, which is expensive to maintain. There's another, less perfect way of detecting API breakage, which is to use the rustdoc tool to export the projects documentation as json. This would let cargo detect whether items had been added, removed or renamed, which covers a large number of cases in which API compatibility is broken. If it encourages developers to up the version number rather than fix the flagged incompatibilities, then it will also drastically reduce the number of incompatibilities in the package repository that can't be detected by rustdoc. While it's impossible to completely eliminate the human element in upholding the version number contract, software can limit the number of errors in the system.

[steveklabnik]

> which is to use the rustdoc tool to export the projects documentation as json.

Side note: it already does this by defaut: http://doc.rust-lang.org/search-index.js

I'm not sure if that's enough information to do this analysis, but the basics are there! I've opened an issue: https://github.com/rust-lang/cargo/issues/47

[awj]

How hard would it be to get usable type signatures out of the compiler as well? It seems like diffing two sets of type signatures would capture everything but purely semantic api incompatibility. Also seems like "here's a machine-readable version of all the types in this package" is a useful thing for a compiler toolchain to produce.

Because, of course, Mozilla is paying you to sit around on your hands.

[steveklabnik]

It shouldn't be that bad, given the need for the compiler to export an AST.

[ripter]

Npm require modules to follow semver. https://www.npmjs.org/doc/package.json.html#version

Now sure why you think the culture there doesn't respect semver.

[TheHydroImpulse]

Requiring a version number to be within the semver format is one thing; but abiding by the rules of semver is another thing entirely. You'll see plenty of Node packages break compatibility on minor or patch updates. It's not something I see as extremely important in that community.

[oakaz]

I don't expect that since the version field is optional.