Support modifying the current package's version (version key in Cargo.toml)

[pitaj]

Essentially provide the functionality of npm version

• cargo version <newversion> sets the version of the current package to <newversion>
• cargo version [major | minor | patch] increments the major/minor/patch version of the current package
• setting the version obviously modifies the version field in Cargo.toml
• but optionally also creates a git commit and tag

One issue I am aware of is that overriding cargo subcommands isn't possible, so an alternative to version would likely need to be used. Some options:

• modify-version (too long IMO)
• semver (my fav)
• ver
• vers

I am creating this issue because it's recommended in CONTRIBUTING.md to create one before creating a PR. I am just now beginning the implementation of this command. I will begin the implementation with the name semver, but I intend to make it easily modifiable.

[albx79]

would be really useful for our workflow.

I suggest calling the command set-version.

[epage]

From #471: Add support for cargo bump-version

Name is TBD but I think helping users bump versions would be useful. In particular, for workspaces, when changing one crate's version, you need to update all of the dependent crates to the new version.

This logic lives in cargo-release today and could be pulled out. I'm assuming it'd need to be copy/paste, that there wouldn't be a good abstraction for sharing the logic since its tied into all of the other decision making in cargo-release.

In-scope

• Crate selection is same as cargo (--all, --exclude, etc)
• Default behavior is if pre-release { remove pre-release } else {update smallest field }
• Support absolute bumps (1.0.0)
• Support relative bumps
  • By field (major, minor, patch)
  • By semantics (break, feature, fix)
  • Additionally allow specifying absolute pre-release (cargo bump-version patch --pre alpha)
• Update all dependents in a workspace

Out-of-scope:

• Release management (tagging, changelogs, etc). Instead, see cargo-release.

[pksunkara]

From the reddit post,

I'd like to see something like cargo workspace version integrated into cargo-edit on the path to being in cargo

While we can share code, I don't agree with this statement. One of the big thing about cargo-workspaces is that it's interactive UI which would be lost with this. Also the git integration would be lost.

[epage]

I guess I didn't look closely enough at what cargo workspace version does. I more was meaning the subset of functionality for modifying versions

[pksunkara]

Subset functionality of modifying versions

I agree. The main blocker for this is that I am not happy with toml_edit. It always ends up modifying the Cargo.toml. I used a regex based solution as shown here but it's not 100% perfect as shown by this test case.

What we need is to finish the editing capability in https://github.com/matklad/tom (which is like rust-analyzer for toml). That's the next thing I had planned to be focusing on once clap v3 was released.

From reddit post,

Once cargo depends on toml_edit

I was asking for a link to discussion because I wanted to point out the deficiencies of toml_edit and why tom is better.

[epage]

What we need is to finish the editing capability in https://github.com/matklad/tom (which is like rust-analyzer for toml). That's the next thing I had planned to be focusing on once clap v3 was released.

btw another one in this field is https://github.com/tamasfe/taplo

I was asking for a link to discussion because I wanted to point out the deficiencies of toml_edit and why tom is better.

Ah, I thought you were asking for a link about cargo add modifying the workspace, not about toml_edit being used by cargo. That issue is rust-lang/cargo#5586

Personally, I think the focus should be on getting a format preserving parser into Cargo so we can unblock cargo-edit being merged. That is a high value tool with a lot of interest and has been "good enough" for a lot of people. We shouldn't block the inclusion on the theoretically perfect tool that is no where near ready to use (or at least I assume so since tom is a 0.0.1 and hasn't seen any work in a year.

[pksunkara]

That is a high value tool with a lot of interest and has been "good enough" for a lot of people. We shouldn't block the inclusion on the theoretically perfect tool

I do agree. My issue is that toml_edit is not "good enough" according to the experiments I did a few months ago (unless something massively changed recently). And I personally think instead of focusing to make it good enough, I would rather focus on tom. Anyway, let's continue this discussion on that ticket. I will paste relevant comments from here to there once I read through that issue. Thanks for the link.