Unable to parse the version number in a multi-package workspace if a package includes a v

[Michael-F-Bryan]

I've got a project with multiple different components, wit-language-server, tree-sitter-wit, wit-compiler, and vscode-plugin. When I'm ready to cut a release, I'll merge a Release PR (in this case, Michael-F-Bryan/wit-lsp#2) and Release Please will automatically update the changelog, create tags, and create a GitHub Release for each component being released.

From there, I'm using cargo-dist to make a nice bundle and installer for the wit-language-server binary.

The "plan" step for my Release workflow just failed (build logs) with the following:

  × Couldn't parse the version from the provided announcement tag (vscode-plugin-v1.1.0)
  ╰─▶ unexpected character 's' while parsing major version number

I assume this is just an issue where we do tag.split_once('v') to extract the version number when we should actually be using tag.rsplit_once().

[Gankra]

So the problem here is actually a bit different. I specifically didn't want to have this kind of tag ambiguity, so cargo-dist's tag parser actually passes in a list of known package names, and will only ever recognize those as prefixes. If it doesn't see them, it will assume your tag is essentially just a version (with optional gunk like v prefixes).

The issue here is that vscode-plugin isn't actually a package in your (cargo) workspace. Even if we did parse it properly, cargo-dist would error out and complain that there's no such package, as it by default doesn't want to allow for the existence of releases not managed by cargo-dist. This is considered valuable to avoid typos causing chaos.

Do you actually want cargo-dist to do something for those releases, or do you just want it to ignore them? Assuming the latter:

We do have the tag-namespace feature as a way to say "hey all the tags cargo-dist needs to care about will contain this prefix", but tree-sitter-wit is breaking the mold there as well. If your tag formats aren't set in stone, making them fit a simple pattern would work well.

You could also use the dispatch-releases feature to make it so that you need to manually tell the cargo-dist workflow to run on a particular tag.