Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Move to Semantic Versioning #1068

Closed
vmalloc opened this issue Sep 3, 2019 · 14 comments

Comments

@vmalloc
Copy link
Contributor

commented Sep 3, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 3, 2019

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

@vmalloc

This comment has been minimized.

Copy link
Contributor Author

commented Sep 3, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 3, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 3, 2019

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

@JohnTitor

This comment has been minimized.

Copy link
Member

commented Sep 3, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 3, 2019

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

@vmalloc

This comment has been minimized.

Copy link
Contributor Author

commented Sep 4, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 4, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 4, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 4, 2019

Because crates depend on actix-web 1.0

@vmalloc

This comment has been minimized.

Copy link
Contributor Author

commented Sep 4, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 4, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 4, 2019

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

@vmalloc vmalloc closed this Sep 4, 2019

@SpaceManiac

This comment has been minimized.

Copy link

commented Sep 8, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.