Feature request: build pipeline should fail if Git tag doesn't matched with the package.json version

[favoyang]

Feature request

Feature category

• [ ] Website: improve the way to browse or discover packages.
• [x] Pipelines: improve the way to publish or manage a package.
• [ ] Registry: improve the registry server.
• [ ] Unity Editor: improve how OpenUPM works with the Unity Editor.
• [ ] Documentation
• [ ] Others

What problem does this feature solve?

The current build pipeline allows the publication of a version even if the Git tag does not match the package.json version. This is partly because Git tags can be quite flexible; for example, the author may use a prefixed tag like 1.0.0-upm, while the actual version is 1.0.0. Without validation of this match, an author could mistakenly publish the wrong version, such as a Git tag of 1.0.1 while the package.json version remains 1.0.0.

How should this be implemented in your opinion?

It is better to let the build pipeline fail if the Git tag does not match the package.json version.

Are you a regular backer or sponsor at patreon.com/openupm?

Yes.

Are you willing to work on this yourself?

Yes.

[Denis535]

My repository contains a few pacakges with a different versions. So, a git tag cannot match all versions of my packages.

[favoyang]

The rule should be fine with monorepo.

A monorepo example

com.denis535.addressables-source-generator 1.0.37
com.denis535....

For example, when handling the latest Git tag: 1.0.174 for com.denis535.addressables-source-generator, the current build pipeline will find that the package.json is still 1.0.37. And raise a build error with message E409 (the version already exists).

After this change, it will still fail, but with a new message: the Git tag version (1.0.174) doesn't matched with the package.json version 1.0.37, which is more clear.

BTW, to avoid these unnecessary failure builds, you are suggested to use gitTagPrefix in the package meta file to filter the Git tag for your package. It's one way to manage a monorepo.

[Denis535]

Honestly, I didn't understand anything. I just want to publish my packages and not bother. For example I have packages:

com.denis535.addressables-extensions v6.6.6
com.denis535.addressables-source-generator v7.7.7

But git tag v10.10.10. Now it works. And I'd like it to work further.

[favoyang]

@Denis535 do you mean that as a monorepo, your Git tag (v10.10.10) has nothing to do with any package version (com.denis535.addressables-extensions@6.6.6)?

[Denis535]

has nothing to do with any package version

Yes. I could update my packages with versions v1.2.3 and v.3.2.1 but commit with git tag v.7.7.7.

[favoyang]

@Denis535 In such a case will the prefixed Git tag work for you?

i.e. when you're ready to publish com.denis535.addressables-extensions@6.6.6, you manually create a Git tag: com.denis535.addressables-extensions/6.6.6. And OpenUPM can track the com.denis535.addressables-extensions/ prefix to find the right Git tags.

The problem with your current Git tag pattern is that it missing a connection for the Git tag and monorepo packages. It brings a little trouble when debugging a specific version, how to quickly find the Git tag for a specific versioned package.

Another completely different strategy is to align your package with your Git tag. i.e. when you create a new Git tag v7.7.7, for the packages you want to publish, you manually set their version to 7.7.7.

Both ways have pros and cons, prefixed Git tag is more popular in the OpenUPM community.

[Denis535]

you manually create a Git tag: com.denis535.addressables-extensions/6.6.6

Maybe this is a good idea. But all these little things take time to get into them. A lot of people might just give up.

[favoyang]

But all these little things take time to get into them. A lot of people might just give up.

IMO, most monorepo on OpenUPM are already using the gitTagPrefix to filter Git tags. It's a feature that has been there for a long time.

If you want to follow this way, you don't need to migrate any existing Git tags, just start it with the next version. It's not a lot of work anyway.