Version number management and PRs

[diconico07]

This issue is the result of a first discussion on the subject during the August 2023 community call.

Description of the current situation

We currently mandates every PR to manage the project version number and increase it as needed.
This is checked by a GitHub action, that doesn't allow merging if this condition is not met.

This is needed as we want the akri-dev helm chart to be published for every merged PR that impact its content, so that anyone can easily test the current development version of Akri.

When merging a PR this test doesn't run again and allow a maintainer to merge another PR that will then not change the version number.

Moreover, it is quite painful as a reviewer to have all the files with version number bumps in every PR.

Possible ideas raised during the discussion

We all agreed that we should find a way to remove the need to manage version numbers management in PRs, here are the different propositions for its successor (feasibility was not checked), that do or do not change much to the release and numbering process

Manual version management on release (by @johnsonshih)

On PR merge, a GitHub action bump the patch version automatically.
When cutting a release we decide whether we should bump minor or major and do that manually at this moment.

Label based version management (by @yujinkim-msft)

Mandate every PR to have a label indicating whether it should bump the patch/minor/major version (checked by a GitHub action or bot)
On merge a GitHub action bump the version according to this label.

Conventional commit version management (by @diconico07)

Mandate every commit/PR to follow conventional commit, this is checked by GitHub action/bot on PRs (like this bot or this action).
Then on main push a GitHub action (like this one) can determine the next version to use, from commits since last release and let the workflow publish a semver pre-release (e.g. 0.12.0-rc1) with the RC number being the number of commit since last release.
For the release process I see two sub possibilities:

• We can then make a manual GitHub workflow for cutting a release that will effectively bump the version files to the required version and make/publish the release
• We can use an action/bot to maintain a release PR that we can merge to cut a release

---

The goal of this issue is to start the discussion around this topic and find a way to solve the issue, so feel free to add any other idea you may have.

I included who made each proposition initially, so we don't have to make any "this is my proposition" disclaimer.

[johnsonshih]

we can also consider add the commit id to the version number, (e.g., 1.2.3-alpha.1+ef365) and manually update the major, minor, patch at release time.

[kate-goldenring]

I like the idea of only bumping version during releases and otherwise updating the release candidate number. Rather than getting RC number from past commits, could we just get current version in version.txt (0.12.0-rc2) and update it?

@diconico07 I am a little concerned about the ability to follow "Conventional commit version management". If i understand this correctly, it means that we will need to ensure everyone squashes their commits before we merge and properly formats them. Plus, we need to make sure version updates are ignored for changes that do not require version bumps.

[diconico07]

RC versions are in <next-version>-rcX format, so to use that we would need to know what is that next version somehow, and as the idea is to remove the version number management burden from both contributors (they don't have to update the version number) and maintainers (they don't have to check the version number got upgraded) for PRs, I fail to see how this could be done without having a way to automatically know what part of the version number to bump after merge (this can't be done before merge, else we end-up with the exact same issue we currently have)

Conventional commit is a way to automate this, as a script is able to tell that any PR/commit (as we use squash&merge strategy, the commit title will be the PR title) means a patch (if it's a fix: prefix), a minor (if it's a feat: prefix) or a major (if prefix is decorated with a !), other prefixes meaning no upgrade (this can be customized, as we may want to say that only tests and docs prefix are synonyms to no version bump).

For this we would use a bot to ensure compliance (the same way we currently have a bot to ensure DCO compliance)

I agree it could stop to the last commit that changed the version number (instead of the last tag), but that's a detail I think.

[github-actions]

Issue has been automatically marked as stale due to inactivity for 90 days. Update the issue to remove label, otherwise it will be automatically closed.

[sftim]

BTW, you can convert this issue to a discussion if you like.