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

Make default baseline the previous stable version in the registry #55

Closed
Tracked by #61
epage opened this issue Aug 9, 2022 · 5 comments · Fixed by #93
Closed
Tracked by #61

Make default baseline the previous stable version in the registry #55

epage opened this issue Aug 9, 2022 · 5 comments · Fixed by #93
Labels
A-cli Area: engine around the lints C-enhancement Category: raise the bar on expectations

Comments

@epage
Copy link
Collaborator

epage commented Aug 9, 2022

With just cargo semver-checks in package directory, it should take the current version and select the previous one. For pre-release versions, it should select the previous non-pre-release as breaking changes between prereleases is fine.

@epage epage added A-cli Area: engine around the lints C-enhancement Category: raise the bar on expectations labels Aug 9, 2022
@obi1kenobi
Copy link
Owner

For other folks reading this issue: this logic is already implemented in the GitHub Action that runs cargo-semver-checks.

This issue is about moving some of that functionality into cargo-semver-checks itself to make it easier to run the tool directly via the CLI, as opposed to running it as a GitHub Action.

@epage
Copy link
Collaborator Author

epage commented Aug 9, 2022

Is the action correctly handling pre-release? imo the default should not select a previous pre-release but the previous stable release

@obi1kenobi
Copy link
Owner

Good question. Agreed on the desired behavior. Have not tested it but I'd guess it would pick pre-releases like so:

  • 1.2.3-alpha.1 would compare to 1.2.2
  • 1.2.3-alpha.2 would compare to 1.2.3-alpha.1
  • 1.2.3 would compare to 1.2.3-alpha.2

I believe this produces an equivalent result because semver-checking is transitive: if all those transitions are individually valid then 1.2.3 compared to 1.2.2 is valid too. But probably still worth changing when moving the logic into cargo-semver-checks itself.

@epage
Copy link
Collaborator Author

epage commented Aug 9, 2022

Expected result

  • 1.2.3-alpha.1 should compare to 1.2.2
  • 1.2.3-alpha.2 should compare to 1.2.2
  • 1.2.3 should compare to 1.2.2

Unfortunately, it is not transitive for pre-release because you are allow to make breaking changes between pre-release versions.

@epage
Copy link
Collaborator Author

epage commented Aug 19, 2022

#92 fixed some related pre-release issues

@epage epage closed this as completed in #93 Aug 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cli Area: engine around the lints C-enhancement Category: raise the bar on expectations
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants