[Unity] Azure Pipelines doesn't change package version

[waitxd]

Is your feature request related to a problem? Please describe.

Current published version of MessagePack-CSharp is v2.2.85.
Version defined in Unity's upm package.json in repository is still v2.2.60.
https://github.com/neuecc/MessagePack-CSharp/blob/2328df7cc3b4b84fd0842d07390a25b9043959c5/src/MessagePack.UnityClient/Assets/Scripts/MessagePack/package.json#L4
Version defined in released v2.2.85 unity package (MessagePack.Unity.2.2.85.unitypackage) is still v2.2.60 too.

Version mismatch between released package and package.json breaks OpenUPM pipeline.

Describe the solution you'd like

Automatic versioning for package.json via Azure pipelines.
Version can be increased via npm version <version> and then committed with [skip ci] in message to avoid triggering a CI build again.
Something like (not tested, just for reference):

- task: Npm@1
  displayName: 'Bump upm package.json version'
  inputs:
    command: custom
    verbose: false
    customCommand: 'version $(Build.BuildNumber)'
    workingDir: "src/MessagePack.UnityClient/Assets/Scripts/MessagePack"

- task: CmdLine@2
  inputs:
    script: |
      git config --global user.email "[email protected]"
      git config --global user.name "Azure Pipeline"
      git commit -m "Bump upm package.json version to $(Build.BuildNumber) [skip ci]"
      git push -u origin HEAD:master

Describe alternatives you've considered

We can manually do versioning for package.json each release. But as OpenUPM log shows that's not an error prone way.

[AArnott]

Duplicate of #1000

[AArnott]

The version number is incremented with each commit anyway. So running npm version to author yet another commit to advance the number would require a manual commit after every single PR. That's not going to happen. We can certainly manually update the version.json file in our CI build itself so that the unity package we build has the right version. We would do this without ever committing the change, because adding a commit just to update a servicing version is lame.
That's what the work tracked by #1000 was to do, but nobody got to it so it closed due to inactivity.

[waitxd]

Unfortunately, fixing build number in release package is not enough for OpenUPM to pick up new version.
Changes in package.json must be made in the repository itself.

<...> because adding a commit just to update a servicing version is lame.

What do you this about making another branch for upm only and incapsulating all lameness there? :)
We can feed this upm branch to OpenUPM and document how to obtain upm version from Unity without OpenUPM:
Unity's Package Manager is able to pick source from branch, e.g. https://github.com/neuecc/MessagePack-CSharp.git#upm

Or, if we are speaking about branching, we can just commit content of *.unitypackage and package.json with increased version due release stage of CI to another branch.
I found that this project uses that approach (master + UPM branches): https://github.com/sebas77/Svelto.ECS/tree/UPM

[AArnott]

we can just commit content of *.unitypackage and package.json with increased version due release stage of CI to another branch.

Yes, if OpenUPM is opening the repo from source instead of the packages we build, then that seems like a reasonable solution.

[neuecc]

My other repository, I've changed release flow,use GitHub Action's run workflow
do run-workflow, update package.json and git push(with new version tags), and create release.
https://github.com/Cysharp/UniTask/blob/master/.github/workflows/build-release.yml

[waitxd]

My other repository, I've changed release flow,use GitHub Action's run workflow
do run-workflow, update package.json and git push(with new version tags), and create release.
https://github.com/Cysharp/UniTask/blob/master/.github/workflows/build-release.yml

If I understood correctly @AArnott doesn't like versioning commits like this one even for release workflows.

Here (in MessagePack-CSharp) git height is used for versioning. So each meaningless/versioning/infrastructure commit increase patch version and bloat git history.
And since package.json is used only for subset of consumers (Unity) of this library it's probably a good idea to publish upm-related content to another branch, or even read-only repository or move to branch via git subtree split.
The second option I see is to provide another "official" way to consume upm packages (e.g. push to custom npm registry due release workflow) and remove package.json from the repository at all.

Personally, I'm ok with any path we choose if we solve main issue: provide stable and reliable path to discover, install and upgrade for upm users.

[AArnott]

I'm not against version-only commits around releases. We could write a little script in the repo that we use to update the package.json file and commit and tag it as a release. You wouldn't get a matching version between the built product and what the source represents on every commit, but you'd get an update in source for each release and if UPM opens the repo at a tag (which I would highly recommend anyway), then you'd be good.

Does that sound like a reasonable solution?

[waitxd]

Sure, updating package.json only for releases is reasonable. I didn't propose to make this for every commit either.
By the way, npm version can be used as this little script. It can update version, commit and tag (documentation) and can be used as an early validation of semver compliance.

OpenUPM's pipeline is triggered via release, so its fine to update package.json at release time.
As for direct consumption from Unity we can document it and embrace Unity's users to use only tagged releases, e.g.:

{
  "dependencies": {
    "com.neuecc.messagepack": "https://github.com/neuecc/MessagePack-CSharp.git?path=/src/MessagePack.UnityClient/Assets/Scripts/MessagePack#v2.2.85"
  }
}