[Feature Request] Allow to source version bump type from branch name

[iautom8things]

Thank you for providing this Github Action for everyone! We are in the process of moving from Concourse to Github Actions, and I found that your action is the closest one to behaving how we like to handle semantic versioning.

I noticed that you have v5 planned, and it seems like you might have this use case in mind. But just in case you don't, I wanted to lay out a feature that we would appreciate seeing in v5.

---

Feature Request

Allow users to choose between sourcing the version bump type (major|minor|patch) from the branch name, instead of the git log commit message.

Use case

We use a branching strategy that involves prefixing the branch to indicate what the intended semantic version change would be.

Examples:

MAJOR

• major/
• breaking/

MINOR

• minor/
• feature/
• feat/

Any other branch name would yield a PATCH version bump.

[PaulHatch]

Hello Manuel,
Yes, this can be accommodated.

So looking at the current "pipeline" there are several steps, for example:

• Determine the last commit that was released
• Determine the last version number
• Determine the type of version
• Produce the version output

The idea for v5 is that these will be injected functions rather than coded directly, allowing behaviors to be switched out. I am planning to include a module to use branch names to determine the commit type as mentioned in #22.

[PaulHatch]

See release of version 5.0.0, I have been playing with a BranchLastReleaseResolver implementation to enable this feature, but there are some issues with this strategy. If the version branch falls in the history for the current HEAD, this is perfectly easy. If the version branch has forked, it is still possible to resolve the common root where the two diverged using a git merge-base command and use that commit as the starting point for this release, however if that branch is merged back into the branch being deployed (for example a hotfix being merged back into master), it screws up the version and potentially starts regenerating versions/increments that have already been produced for other commits. None of the options available seem to be able to resolve this, which makes sense as information has essentially be destroyed with the branch merge.

Possibly you could just "be careful" with this, but I'm going to give it a bit more thought first.

[PaulHatch]

The new behavior for version 5 going forward will be to sort by the version number itself rather than the date. This should be sufficient to cover edge cases here. As of the most recent commit, setting the use_branches input to true will enable this behavior. Please let me know if you encounter any issues with this.

[btrautmann]

The new behavior for version 5 going forward will be to sort by the version number itself rather than the date. This should be sufficient to cover edge cases here. As of the most recent commit, setting the use_branches input to true will enable this behavior. Please let me know if you encounter any issues with this.

Hey @PaulHatch, thanks for this recent feature. It's a great addition, but unfortunately I don't believe it will work for our purposes -- but I wanted to be sure before we moved on (because if I'm correct, I don't think it would make sense to change the behavior to meet our needs).

Our current branching strategy for releases is that we branch off of main, creating release/<app-version> branches. Once released, we generally tag the released commit on that branch, but we never merge these branches back into main. For fixes, we generally patch main first and then cherry-pick these commits to the correct release/* branch (which I believe is also unorthodox). Due to the usage of --merged in the DefaultLastReleaseResolver it would seem that no branches would be returned for for-each-ref and therefore no usable versions are found resulting in 0.0.1 as the output.

Is this summary correct? I believe the "solution" would be for us to 1) make fixes during release cycles to release/* branches and 2) merge these release/* branches back to main. The issue with that is that we only allow squash commits, so we'd essentially be squashing an entire release/* branch into a single sha which I believe would not contain the tag that was associated with the tip of the release/* branch prior to merging (I'm not a git master, so feel free to correct me here).

[PaulHatch]

Sorry I missed this question until now, but just in case some one else comes across it, you are correct with the current implementation. In v5.0.0 the branch must be merged to be picked up.

In general I think the current versioning based on branches is somewhat primitive, branch version is complicated because branching strategies impact the shape of the commit graph significantly. It may be necessary to provide multiple branch-type versioning providers to accommodate different branching strategies. I've created ticket #76 to revisit this in the next feature release.

In the meantime I am closing this ticket as branch versioning is supported in v5.0.0.