Is there any way to disable global version tag?

Is there any way to disable the global version tag?

When having multiple crates in the workspace that have a different release schedule I want to be able to disable the global version tag on minor/patch releases and turn it back on when making a major release.

Is it currently possible?

You will have to explain your use case a bit more with examples. What is the global version tag you are talking about here?

I'm sorry for being too generic.

For example, in my use case, I have the following workspace structure

workspace
|-- package_1(cli)
|-- package_2 (lib)
|-- package_3 (cli)

Package_1 a cli util that does not depend on the Packages_2,3. package_3 depends on package_2.
Packages_2,3 updates much more frequently than package_1.

Let's say I did a major release for all the packages and now all of them have the same version. For example 1.0.0

The following tags were created:

package_1@v1.0.0
package_2@v1.0.0
package_3@v1.0.0
v1.0.0

After that, there were small patches in packages_2 and package_3 and now their version is 1.0.4 but package_1 is still with the version 1.0.0

The problem is when only the package_1 have changes then cargo workspaces version fails with an error
error: unable to tag v1.0.1, out = , err = fatal: tag 'v1.0.1' already exists

Ideally, I want the global version tag to be created only on major releases of the whole workspace and not for each package version bumps.

I hope I succeeded to explain it a little bit better.

The problematic part is this one

cargo-workspaces/cargo-workspaces/src/utils/git.rs

Line 207 in 3464a4e

if let Some(version) = new_version {

This leads to the creation of the global version tag vX.Y.Z in addition to the package's individual tag package_name@vX.Y.Z thus leading to git push conflict when packages updates are not synchronous.

@pksunkara,
Maybe it's worth adding a boolean flag global_version_tag or workspace_version_tag to control whether the tag vX.Y.Z is going to be created defaulting to false as cargo-workspaces intended to be used on workspaces with multiple packages?

I am thinking the solution is to add a new option --no-global-tag similar to --no-individual-tags we already have.

Yeah, the --no-global-tag should be enough... at least for the use-case I described

Would welcome a PR since I am a bit busy with other projects right now.

Hi @pksunkara,
Is it possible to make a release with a #49 PR?