Need an option to increase patch version using commit message

[naveenkumarvr]

Hello Author,

Thanks for the action it is really useful.

Is there any way to increase the patch version using commit message similar to Major and Minor version. I understood that by enabling bump_commit: ture the patch version is automatically updated. But I want to update the patch version only based on my commit message like "fix:" or "bugfix:"

Is there any provision in this action similar to that.

Thanks and Advance,
Naveen

[PaulHatch]

Hey Naveen, thanks and glad you find it useful.

So I think what you're saying is that you want the behavior of bump each commit, but only for cases when the commit message matches a new patch pattern?

[naveenkumarvr]

Hi Paul,

Thanks for your quick reply

Yes, I don't want to bump up the "patch" version on each commit, I want to increase it based on commit message like we do for major and minor. Example : "fix: or something

Is there any way to implement this

[naveenkumarvr]

Hello @PaulHatch ,

Could you pls check the above request and help me on this.

[PaulHatch]

There is not currently a way to do this (aside from using tags/branches with the normal flow). It could be added. I worry about adding a "patch_pattern" type input to the API creating confusion. This "bump each commit" behavior is not the default, for all current cases patch is the default, and seeing this input people may mistakenly believe they need to provide it, so this would need to be named something like "bump_each_commit_patch_pattern". This behavior could be added to the BumpAlwaysVersionClassifier. I don't have time to implement this right now but I'm open to a PR to add it.

[naveenkumarvr]

Understood . Thanks @PaulHatch

Sorry to bother you.. In that case how to bump up the patch version by setting "bump_each_commit" to false. I used the "tags/branches" model as I tried using "patch/" and <fix/branch name> both doesn't increase by patch version. Am I missing something here.

Please guide me

[PaulHatch]

This is the "normal" mode of operation for this action. On each run this action is predicting what the version will be for the target commit if it were released. Usually when releasing software in a team environment you may not know if your commit is the final commit before a release at the time you are making a commit. There could be other commits added, your changes may fail automated build tests, QA, or UAT, etc. and require additional commits. By predicting the next version without actually committing it anywhere at build time, the option to add commits without impacting the next released version is preserved. When you are ready to release a particular commit, you can tag it using a tag like v1.2.3. It is also possible to use a branch in a similar manner, but I'd strongly recommend using tags unless you need to maintain ongoing releases for multiple versions simultaneously.

[PaulHatch]

Now available in v5.1.0