Fix dist-tag incorrectly assigned to the first release candidate for a minor iTwinjs update

[MikeNBentley]

Resolve Issue #1125

• Description: The first release candidate for a minor iTwinjs update has the dist-tag set to nightly instead of rc

• Proposed solution: After discussing with Dan and Mike, one valid solution is to swap the job order in Version Bump pipeline. In short, we go from:

  CheckPrevCommit → Bump → CreateBranch → UpdateMaster

  to:

  CheckPrevCommit → CreateBranch → Bump → UpdateMaster

  The reason for that is for the first release candidate, we will trigger the pipeline from the master branch, which will in turn assigns the dist-tag to nightly instead of rc based off the logic in this file

• Affected File(s): common/config/azure-pipelines/jobs/version-bump.yaml

---

These are more details explaining about the PR:

• Why does this work?

  Originally, with the job order: CheckPrevCommit → Bump → CreateBranch → UpdateMaster. In Bump job, we will bump the version → push a commit with a message in format x.x.x-dev.x in master → trigger fast-ci pipeline → run publish.yaml script → run gather_packages.py which will assign the dist-tag to nightly because we start off with master branch. Note the condition in the python file:

  if mainBranch in branchName:
    distTag = "nightly"

  Now, with the job order: CheckPrevCommit → CreateBranch → Bump → UpdateMaster We will create and checkout to release branch first (e.g. release/4.9.x) → bump the version → push a commit with a message in format x.x.x-dev.x in release/4.9.x → trigger fast-ci pipeline (but now the source branch triggering the pipeline is release/4.9.x) → run publish.yaml script → run gather_packages.py which will assign the dist-tag to rc because we start off with a release branch (trace the logic in python file for more details)

• What this PR will fix and will not fix?

  The first release candidate version should be assigned with dist-tag rc. For example, we have 4.8.0-dev.41 as our latest dev version. When we trigger the Version Bump with parameter BumpType=releaseCandidate, we will update and push 4.8.0-dev.42 commit in release/4.8.x branch (instead of master branch). Then we will come back to master, update and push 4.9.0-dev.0 in master (please refer to UpdateMaster job)

  However, if we want to upgrade the version directly in release branch, for example, in case of a backport during release process, we still need to trigger the Version Bump pipeline on release branch with parameter BumpType=nightly. This PR will not fix that.

• Summary what needs to be changed as the result of new job order

  • As these four jobs still need to be run sequentially, dependsOn and condition are modified accordingly

  • Condition like ${{ if eq(parameters.BumpType, 'releaseCandidate') }}: will be moved to condition or the dependencies will not resolve

  • The version we need to format release branch name (e.g. the 4.8.x in release/4.8.x) now not got from Bump job but from the latest commit with message in format x.x.x-dev.x (for example, we will get 4.8.x from 4.8.0-dev.41 instead of from 4.8.0-dev.42)

  • In Bump job, when we do release candidate bump, we have to checkout to release branch and push to that release branch accordingly

  • All other details like in UpdateMaster should stay the same

[MichaelSwigerAtBentley]

Previously, the first RC would be in master: https://github.com/iTwin/itwinjs-core/commit/1d087ebdca73a01993a1ecd0f6f1bcb9a9682767

With this change, this is no longer the case, right?

Do we want/need to port that commit to master?

[MikeNBentley]

Previously, the first RC would be in master: 1d087eb

With this change, this is no longer the case, right?

Do we want/need to port that commit to master?

Yes, dev.27 should be in release/4.9.x, then we will come back to master to push 4.10.0-dev.0. I think Dan did mention about dev.27 should only be in release/4.9.x but I am not so sure.

[MichaelSwigerAtBentley]

Previously, the first RC would be in master: 1d087eb With this change, this is no longer the case, right? Do we want/need to port that commit to master?

Yes, dev.27 should be in release/4.9.x, then we will come back to master to push 4.10.0-dev.0. I think Dan did mention about dev.27 should only be release/4.9.x but I am not so sure.

I think that makes sense, since all the other RCs arnt in master. But just want to make sure nothing is relying on the first RC being there.

[hl662]

However, if we want to upgrade the version directly in release branch, for example, in case of a backport, we still need to trigger the Version Bump pipeline on release branch with parameter BumpType=nightly. This PR will not fix that.

I'm sorry, I might be confused here - does this refer to backports to release branches during the period of the release process when release candidates go out? This is separate from backports after the release process is finished right..? Because the latter should use BumpType=patch

[MikeNBentley]

However, if we want to upgrade the version directly in release branch, for example, in case of a backport, we still need to trigger the Version Bump pipeline on release branch with parameter BumpType=nightly. This PR will not fix that.

I'm sorry, I might be confused here - does this refer to backports to release branches during the period of the release process when release candidates go out? This is separate from backports after the release process is finished right..? Because the latter should use BumpType=patch

Sorry for the confusion, I do want to refer to the backports during release process. Thank you for the clarification!