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