New version schema suggestion

[MariusStorhaug]

Current versioning practice for modules can cause collisions and does not make sense when generating the preview versions.

Example scenario based on current method

Lets look at an example run where we would do a patch change on the fileShares module:

1. A new branch is created for further development of the fileShare module.
2. Bug-fixes, documentation, and security updates are added to the fileShare module by the author. The version.json file is not changed in either the child or parent module folders.
3. The author runs a manual workflow based on their development branch, with the 'publish pre-release' option enabled.
4. A prerelease run of publishing triggers after test and validation of the module.
   • For the child and parent modules, the module version's major and minor version is read from the version.json file in the module folder respectively.
   • The patch is calculated based on the total number of commits in history on the branch (independent on the module).
   • As the pipeline is not running based on the 'default branch', a prerelease segment (-prerelease) is added to the version.
   • The version results in being 0.3.501-prerelease. The child and parent modules may have different major and minor versions, but the patch version will be the same in this case. Other unmodified child modules of storageAccount will not be republished and remain with the existin version.
5. Sequential commits on the branch and runs of the module pipeline, with the 'publish pre-release' option enabled results in the following versions being published:
   • 0.3.502-prerelease
   • 0.3.503-prerelease
   • ...
   • 0.3.506-prerelease
6. When the branch is merged to the default branch, the only thing that changes is the patch version and the removal of the -prerelease segment.
   • The number of commits will at this point be calculated based on the number of commits on the default branch.
   • Assuming the development branch started from commit 500 on the default branch, and the author added 6 commits on the development branch, the prerelease versions will reach 0.3.506-prerelease.
   • Meanwhile, there can be changes (let's say 2 squashed PR merges) on the default branch that is pushing its number of commits in history further.
   • If the PR for the changes to fileShare is squash merged as commit number 503, the patch version on the child and parent module is then 503, resulting in a version 0.3.503 being published.

                  \         \
C499 -> C500 ---> C501 ---> C502 ---> C503 (503)
        \                            /
         D1 --> D2 --> D3 ... --> D6
        (501)  (502)  (503)      (506)

Cx - Commits on main, Dx - Commits on development branch, (x) - Calculated patch version

Suggesion for change:

• Major: from version.json
• Minor: from version.json
• Patch: Static, based on the number of commits from the parent commit of your branch back to start (static number), i.e git rev-list --count main --first-parent

• Pre-release label: "-preview###" where ### is numbers of commits from parent commit. aka starting on 0 or 1 and incrementing by 1 per commit. i.e [int](git rev-list --count $Commit ^main)

  • Assuming the development branch started from commit 500 on the default branch, and the author added 6 commits on the development branch, the prerelease versions will reach 0.3.500-prerelease6.
  • Meanwhile, there can be changes (let's say 2 squashed PR merges) on the default branch that is pushing its number of commits in history further.
  • If the PR for the changes to fileShare is squash merged as commit number 503, the patch version on the child and parent module is then 503, resulting in a version 0.3.503 being published.

i.e.

• 0.3.500-prerelease1
• 0.3.500-prerelease2
• 0.3.500-prerelease3
• 0.3.500-prerelease4
• 0.3.500-prerelease5

Or use short commit hashes:

i.e.

• 0.3.500-prerelease043ff3e4
• 0.3.500-prerelease684c8487
• 0.3.500-prerelease195805a3
• 0.3.500-prereleasef7ca429e

[rahalan]

Team decides for option 2 (Hash code)