Ignore major/minor patterns

[Levelleor]

Hey, this is a great action and flexibility is great but I wonder if there's a way to make it work in my case.

I have a release-flow based on branches and there may be branches called v1 or v1.1 in my repo. This will be a release branch to which a tag v1 will be attached later to point to latest stable release. The thing is I want to avoid accidentally jumping to major or minor increments when these are used. It would make no sense for the v1 branch to have a v2.0 release and same for v1.1 to have v1.4 attached to it. For v2 or v1.4 there will be new branches created when we reach to those releases.

So I used the new version_from_branch input and it did detect the version available in the branch but if I use (MAJOR) inside any commit it starts to treat the version as a majorly incremented. I tried setting the patterns to "" nothing basically but that doesn't change the behaviour for some reason, I still got a major increment.

Any way to get to force it to only create minor/patch, only patch in the current state?

[PaulHatch]

It should not be doing this, thanks for reporting.

[Levelleor]

Let me know if you can't replicate it but I think I used a fairly simple case with just branch and version_from_branch being set with everything else being set by action's defaults.
Edit: and the branch was called "test/v1.4" or something like that, just for testing, when this releases it will be set to straight "v1.4"

[Levelleor]

Also, for future consideration it would be awesome to also have a set of features for:

• Pass your own version into the action for it to create a tag for you. It would still be useful to base the version calculation off the base input.
• Instruct action to not increment major/minor patterns. This will impact the calculation sometimes so corner cases will have to be tested but it would be generally useful for people to have the freedom of instructing it of skipping a major in some specific cases.

I think that's about it. These would just make the action infinitely more versatile and injectable into any workflow so there would be no reason to not do that in my opinion.