cargo-edit
cargo-edit copied to clipboard
killercup
Improve cargo set-version for bumping release candidate
Say for example the version is 2.0.0 for a cargo project, and we want to make a rc for a minor version, i.e 2.1.0-rc , but when using
cargo set-version --bump rc , the follow happens:
2.0.0 ---> 2.0.1-rc.1
Expected bump: 2.0.0 ---> 2.1.0-rc.1
So maybe adding a feature which allows us to make a release candidate of all the three semvers (major minor patch) would be useful!
If this feature already exists, do let me know!
The main question has been how to design the UI around it, whether more possible values, allowing comma-separated levels, etc. A short-term workaround is to set the absolute level.
I think it would make more sense for more possible values when choosing rc, like
cargo set-version --bump rc major/minor/patch
One option would be to let --bump rc not increment any version on itself, then it's up to the user to combine it with another operation.
Right now --bump rc seems to be --bump patch+rc (for lack of a defined syntax), which means that it's taken out of the e users hands to decide what part of the version to make a rc off.
Removing the patch part of that would already allow users to combine two commands to get the desired effect and not require to introduce a new syntax.
In other words, the current behaviour would become:
cargo set-version --bump patch; cargo set-version --bump rc
while also allowing all other combinations.
EDIT:
this would also make --bump rc a bit easier to explain on what it does, right now it has two modes:
- bump patch and add rc.0
- bum rc.X to rc.(X+1)
If rc would only change the rc it would be down to "move from current rc to next rc" non -> 0 -> 1 -> 2 ...
The same change (whatever it is in the end) should probably be mirrored for alpha and beta as well so they act in a uniform way
A cargo set-version --bump rc that sets rc but doesn't change any other field is downgrading the version of the crate. I worry that that would be surprising behavior and would prefer to look for solutions that do not go down that route.
That's a fair concern, so how about restricting rc/alpha/beta to only ever bump the rc/alpha/beta version and error if there is non then introduce something like -rc/-alpha/-beta to patch/minor/major?
That would make it explicit, and it would look a bit like the version as it's 0.1.1-rc.0 so patch-rc for turning 0.1.0 to 0.1.1-rc.0 would make some sense at least to me as the -rc repeats in both the command and the result.
Thoughts?
I'm a bit mixed.
Know of any other tools that have relative version bumps and pre-release support? Curious how they handle it.
yes there in leinigen (clojures cargo) they follow the procedure similar to my initial suggestion: https://cljdoc.org/d/leiningen/leiningen/2.9.8/api/leiningen.release
they have:
-
bump-version <level>(for minor, major, patch) -
next-qualifier <qualifier>(for rc, alpha, beta etc)
@epage NPM has this support.
npm version --help
Bump a package version
Usage:
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease | from-git]
Options:
[--allow-same-version] [--no-commit-hooks] [--no-git-tag-version] [--json]
[--preid prerelease-id] [--sign-git-tag]
[-w|--workspace <workspace-name> [-w|--workspace <workspace-name> ...]]
[-ws|--workspaces] [--no-workspaces-update] [--include-workspace-root]
alias: verison
Run "npm help version" for more info
