Support "v" prefix in incremented version

[thekaveman]

Hey there 👋 this looks like a great Action!

I see in the lookup, any v prefix in the latest tag is stripped:

# detect current version - removing "v" from start of tag if it exists
current_version="$( ... | sed 's/^v//g' | ... )"

This makes the increment math way easier!

I wonder if it would be possible to support adding the v prefix back, after the new version is created, if it was there in the first place?

[ps-jay]

Yup, can look at that ..

I think I'd make it an optional flag, rather than automatic

e.g.

        with:
          scheme: semver
          increment: patch
          v_prefix: true   # defaults to false

I hope that would suit

[thekaveman]

An optional flag would definitely work!

I was hoping we could find a way to detect if it was in the previous tag and automatically add it back though? It seems like someone starting with tag v1.2.0 would expect v1.3.0 to be next, and not 1.3.0 (that would be my expectation).

I don't meant to sound harsh, but this Action "enforces" its opinion of what version numbers should look like, rather than incrementing existing numbers/schemes.

[ps-jay]

You are right - it's opinionated. It deliberately strips v characters from the front without adding them back in because that's what I intended at the company I work for. The reason being is that having the v character is not semver compliant, and I was aiming for consistency in the company. This helps us move the minority of projects we had using v prefixed versions to not having them.

I do understand that Golang projects require the v on the front of the git tag. Or there is your use-case where you would like to retain the v for consistency with what your repo has done in the past.

What about an additional output v_version which outputted the calculated version with a v character on the front always? Does that seem like a better solution for you?

[thekaveman]

I appreciate that detailed response @ps-jay, your reasoning makes perfect sense. And I'm right there with you on making tools that at least try to push folks in the right direction towards consistency 😉

Your suggestion of outputting an additional v_version sounds good; it covers both cases and lets the user make the decision.

[thekaveman]

Hello @ps-jay. Just following up to note that I've talked with my team about this "v or no v" issue, and we've concluded that no v is actually better for us! So thank you for entertaining my idea and your willingness to adapt your Action. At this point, we will start using it as-is and don't need the additional feature of a v_version.

Feel free to close this issue, and thanks again!