Actix-web: Move to Semantic Versioning

[vmalloc]

Following up on #947, I think it is indeed time for Actix to start following semantic versioning.
This means mainly that:

1. Fix releases (releases in which only the third digit is incremented) should only contain bug fixes and not new features
2. Minor releases (releases in which the second digit is incremented) can contain both bug fixes and new features which are not breaking backward compatibility
3. Major releases (releases in which the first digit is incremented) can contain breaking changes.

Now that Actix hit 1.0, it is important to communicate new content in this manner so that dependent projects can pin dependencies and not get surprised by new content landing.

[fafhrd91]

Do not overestimate semver, we have to be flexible. Especially in rust context.

[vmalloc]

I'm not sure what you mean by that -- I'm not overestimating it, I just think it is a good practice to follow, and I don't think the cost is too great...

[fafhrd91]

i'd prefer to make small breaking change in fix release rather than bump minor release. also there is no difference in minor/major release in rust, minor release is a major release in rust world.

[fafhrd91]

it is ok to use semver suggestions, it is not ok to blindly follow semver.

[JohnTitor]

IMO: From a dependency perspective, there are differences between major and minor releases (over 1.0). Many Rustaceans seem to use caret-requirements, so I don't think it's a good idea to include breaking changes in the minor version over 1.0.

ref. https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html

[fafhrd91]

I don't understand purpose of this ticket. what is the actionable here?

[vmalloc]

Well, it is more like a request - I think it would be great if additions like the ones introduced in 1.0.6 would merit a minor bump. I'm personally ok with hitting versions like 1.67.2 - I don't see a problem with that. People wanting to keep up with Actix in their projects will always update to the next available minor.

The thing is that at some point some minor version will change something for someone, and in that case, he or she might start looking at the "last version that worked". With semantic versioning, the odds increase that that version would just be the latest fix to the previous minor.

[fafhrd91]

It is not a problem to bump minor version, but then every dependent crate must be updated as well https://crates.io/crates/actix-web/reverse_dependencies and that would be huge problem. Every minor version of actix-web is major update for ecosystem and huge burden for application developers.

[vmalloc]

Why would every single crate have to be updated? If bug fixes are made they will propagate to dependencies. New features would indeed not propagate, but then again people aren't using them yet so that's not such a pain. People who want their projects to benefit from progress made in the actix project (myself included) will periodically run cargo update and then put their code through more testing cycles -- others will just benefit from the fact that their build is reproducible and doesn't need re-testing every once in a while. I believe it is a win-win... Where am I wrong?

[fafhrd91]

Because crates depend on actix-web 1.0

[vmalloc]

Great - it's their choice then between:

1. Staying pinned to 1.0, then benefitting only from 1.0.x bug fixes
2. Staying pinned and periodically updating and pinning to a newer minor, then back to bullet 1 above
3. Living on the edge and pinning to ^1 (or one of the other options) - automatically accepting all minors, which is effectively what happens today, but will once again benefit from the coding conveyed as a part of SemVer, helping people make sense of what changed and when new features actually land.

[fafhrd91]

that is bad answer. nobody depends on ^1, that is just not viable, especially for third-party crates. i develop large application based on actix-net/web, and getting multiple minor updates for very small broken changes would be very annoying, because i'd need to update dependency in multiple places and what would happen, i'd just fork project and start develop my own branch. practical usage is much more important than blindly following some recommendations.

again, what is the actionable for this ticket?

[vmalloc]

I’m guessing if you’re so passionately opposed to it, there is no actionable items.

[SpaceManiac]

Disclaimer: I have no stake in actix-web specifically, and I won't be insulted if you take no action. I simply see decisions being made based on incorrect information.

also there is no difference in minor/major release in rust, minor release is a major release in rust world.

it is not ok to blindly follow semver.

nobody depends on ^1, that is just not viable, especially for third-party crates.

Actually, almost everybody effectively depends on ^1.

Cargo interprets caret requirements (which are the default) such as ^1.0.2 to mean "anything semver compatible", or in other words, >=1.0.2 and <2.0.0 -- which includes any 1.x.y versions. There is no difference between any of 1, 1.0, 1.0.0, ^1, ^1.0, and ^1.0.0.

Semver is used in the Rust world specifically so that Cargo can know automatically whether it is safe to substitute a newer version without breaking. In this regard, a refusal to adhere to semver means that a user running cargo update will suddenly have their builds break -- or a new developer cloning a project without a lockfile will have their builds break when Cargo does the equivalent of cargo update on a first build.

There is no compelling reason to never bump the minor version, which Cargo does treat differently than bumping the major version.