Add --allow-downgrade option to set-version command

[wiktorsikora]

I would like to add an option to allow downgrade version when using set-version command.

In my use case this feature is necessary since our CI/CD needs to create dev packages (deb/rpm) for already released versions.

I have already created PR for this feature (Sorry about that, I misunderstood contribution guidelines 😕)

[epage]

This was previously discussed in #782 (somehow I missed it when previously searching or I would have linked to it).

That was mostly closed because there wasn't a use case to justify the exposing the behavior when moving backwards is generally not what should be done.

In my use case this feature is necessary since our CI/CD needs to create dev packages (deb/rpm) for already released versions.

Can you expand on this. Why are you making packages of source code from a newer version than you are releasing but wanting to release with that old version?

[wiktorsikora]

We are using monorepo with multiple independently versioned components. Components are released through alpha beta and stable channels with versions somehow derived from git commit. The problem occurs when we decide to release stable version of single component. After stable release each subsequent commit to monorepo causes pipeline failure since new calculated version has pre-release part added (downgrade). From our perspective this downgrade is desirable since such version will not be considered as an update by yum/apt package managers. We could immediately update version to next alpha but such version is meaningless as we do not starting development cycle on this component yet.

Described approach is not ideal but for our usecase is perfectly fine.

We are using cargo-edit as a tool to manage versions of application, not source code and for this reason we sometimes want to intentionally break the semver rules. As pointed out in #782 --force options are incredibly usefull. I think this option would make cargo-edit more versatile without sacrificing its main purpose.

[skogseth]

I just want to chime in and say that my colleague was just blocked by this. We're having a problem similar to that of @wiktorsikora where we need to internally release some versions that don't follow semantic versioning. We'll find another way to solve our problem of course, but this feature would have been perfect.

[ctron]

We are just hit by the same issue. I think it makes sense to allow downgrades it the user explicitly states this.

A strategy of preventing the user from making mistakes by default is valuable. A strategy of patronizing the user is not. Even in Rust you can go with unsafe.

I guess our use case is similar to the already reported ones. We have a CI, we use set-version and then git diff if the version is aligned with the tag.

[ctron]

Just for people running into the same issue, looking for a solution.

Install cargo-workspaces: https://github.com/pksunkara/cargo-workspaces?tab=readme-ov-file#installation

You can then run the following command to set any version for a workspace, ignoring changes, not creating a git commit/tag.

cargo ws version custom 0.0.0-alpha.2 --all --no-git-commit --force "*" --yes

[NickLarsenNZ]

I wish there was a --force option. Of course downgrading is not recommended, but you don't know everyone's workflows.

In our case, we cut a release branch and cargo set-version without issue. The problem comes when we have some fixes that need applying to that release, but it is examples and other things that don't warrant even a patch level upgrade. Sure, we should catch those earlier, but here we are.

During these "doc" fixes, we want to cargo set-version in a PR to add build info (eg: current version x.x.x-prABC. So of course, this fails because it is considered a downgrade:

Error: Cannot downgrade from 24.7.0 to 24.7.0-prABC

I guess we'll need to look at cargo ws just to make it work. But I think cargo-edit should make concessions for the variety of workflows its users have, and just perhaps add a warning about the downgrade.

[epage]

During these "doc" fixes, we want to cargo set-version in a PR to add build info (eg: current version x.x.x-prABC. So of course, this fails because it is considered a downgrade:

Build information (+ prefixed) and pre-release (- prefixed) are different things. And semver has no concept of "post-release".

Unless there is something I'm missing in this case, the lack of downgrade in this situation seems to be working as intended as its calling out suspect behavior.

[DavidAntliff]

Sheesh... it's called "set version", not "bump version" or "increase version" or "upgrade version". It should allow the version to be set to anything that is a valid version number.

Initially, it seems like the perfect tool to use for CI control of versioning, except that it doesn't actually "set" the version, it imposes its own rules on what it allows.

Tools should be simple and not try to double-guess their users. For everyone who thought that cargo-edit might actually be useful, but discovered like I did that it has its own opinionated thoughts on what version you can "set", just use sed on Cargo.toml instead.

Time and time again I come across authors of such programs who think they know best, impose their opinions on what the tools can do, and don't realise that what integrators really need is simple tools that do what they say on the tin. We can create and solve our own problems, but not if the tools constantly add their own complications we have to work around. It's tiresome.

UNIX philosophy: simple tools should do simple things. Let us dig our own holes and dig ourselves out of them, we're not children.

[domsleee]

I will add that --allow-downgrade would have been useful for me today.

I was just the program locally to see how tauri updates work, and wanted to revert my change.

❯ cargo set-version 1.6.1
Error: Cannot downgrade from 1.6.2 to 1.6.1

The current message reads as if it is not okay to downgrade in Cargo.toml in any circumstance, which is not correct. For example, building a previous version of a program is a valid use case where the version is downgraded. It was quite frustrating for me to have to type the versions back in manually.

A message like this seems nicer for the user:

❯ cargo set-version 1.6.1
Error: Refusing to downgrade from 1.6.2 to 1.6.1 unless `--allow-downgrade` is used.
Downgrading is not a supported CI workflow, for example, crates.io does not support republishing versions, refer to https://doc.rust-lang.org/cargo/reference/publishing.html.

My thoughts:

• In this case, set-version seems to be opinionated as a CI workflow tool, rather than a convenient way to set the version
• Not having an override is frustrating for users
  • Similar tools like npm version and cargo ws version support it
  • It doesn't justify why it can't be downgraded, it's not clear what the behaviour protects against

[leighmcculloch]

I was blocked today with this also. We use cargo set-version in CI workflows as ways to move versions forward when preparing for releases, and it does a great job of editing all the right files in a large workspace in one swoop. Problem arose when we accidentally used the wrong release candidate version, we used -rc.3.0 instead of -rc.3, but when we run our workflows to change the version to -rc.3, it fails.

The tool presents as a tool for editing cargo files, but it appears to be more opinionated about publishing specifically.

[NickLarsenNZ]

This bites us every release