[Feature request] Inputing sematic version rather then latest tagged

[djshaq121]

Hi @PaulHatch, I have been messing around with this and it works great. Would it be possible for the action takes an input of a sematic version (2.7.0 eg) so it can increment that version rather then the most recently used tagged version? The idea here would be to have a text file with a version. We would read the version value and pass it in to your action for it to update the release. If successful we would update the that text file. We don't tag our commits with the releases.

I did try to get around this by using bump_each_commit but this had the undesired affect of updating the version multiple times when there was multiple commits in a single PR.

Thanks, Shaq

[PaulHatch]

Hi @djshaq121 This has been requested a few times, but you are the first one to describe this use case which I think is a good one, however this leaves a design question--how does the action figure out what the last commit was? Currently the last tag is providing not only the version, but also a list of commits from which the version type (major/minor/patch), the increment count, and the list of committers to the version is derived. I suppose this could just override the version from the tag, but that may be a bit awkward/confusing. I don't think you'd want to have a commit tagged with one version but actually using a different one, and if you're going to ensure that the tags are correct then there's little point to overriding in the first place.

[djshaq121]

Hi @PaulHatch

Sorry for the late response. "how does the action figure out what the last commit was?" I am not sure If can answer this question. I thought it got all of the commits in the checkout branch and looks at the last commit. Is the use case here if there are multiple commits tagged with the same sematic version but different/same version types(major/minor/patch) you need to select the version with the highest change(Major > Minor > Patch) to know how much to increment?

Well My idea here is that if you provide this new input that takes in this semantic version you action will no longer look for release tags on commits. How I imagined this to work, is if you have PR with three commit. Where the oldest commit is Major, middle not provided and newst commit is a patch and we are starting with 1.0.0. it will become 2.0.0(Which i believe already works like this). We can now write the version to a text file to be later passed back to your action.

Maybe I understand you question after writing this. Say we have repo where we don't use tags. We have a main branch with 10 commits and I create a PR with 2 commits. Would your action know to only look at those 2 commits to check how much to increment or would it look at all 12 commits. I am assuming if this action was to run in main it would try and find the last version by tag and check the difference between that commit and last commit. And because there are no tags in main, it would get the first commit and look at all commit messages. I think thats the problem you were referring too, right?

[PaulHatch]

Right, so in your example we would need the version injected as parameter, the action would not be able to figure out which commit was the last one released. In theory the last commit hash could be a second parameter, but doing that would be too complicated and fragile.

Without knowing the last commit we can't check on any of these things mention above that are required to produce the output of the action.

[djshaq121]

Yeah that make sense.