search

vivin / gradle-semantic-build-versioning

Gradle plugin to generate version-numbers and tags using semantic versioning
MIT License
85 stars 32 forks source link

Enable promoteToRelease without the need for a commit #108

Open alex42ree opened 4 years ago

alex42ree commented 4 years ago

Let's say I have a component that has a release 1.0.0. Then I create and tag some pre-release versions of a component, saying 1.0.1-RC.0, 1.0.1-RC.1, 1.0.1-RC.2. Now I want to promote the last pre-release version 1.0.1-RC.2 into a new release version 1.0.1 using "-PpromoteToRelease".

Doing this with the current release of the plugin, I get the error "Cannot bump the version, create a new pre-release version, or promote a pre-release version because HEAD is currently pointing to a tag that identifies an existing version. To be able to create a new version, you must make changes" I could do a commit on the component - but that also changes the component, so it is not the same as the pre-release version that I wanted to promote. Empty commits are not a good practice. I looked into the semver specification and I did not find anything that disallows retagging an already tagged version with a second version tag.

If you like I could create a pull request with that functionality.

vivin commented 4 years ago

Hello,

Sorry for the late response. Let me look into this. I need to think about it some more to see if allowing multiple tags to point to the same commit would break any assumptions.

vivin commented 4 years ago

@alex42ree

Having thought about it, I think this might be fine for the single case where you're going from a pre-release version to a release version. If there is no real difference in the source and you would only be making a commit so you can promote the version, I really don't see any downsides to having a release version tag and its corresponding latest pre-release version tag pointing to the same commit. I don't think it should be possible in any other case, though.

I need to look at the code to see if there are any implicit assumptions that there will never be more than one tag per commit.

I would definitely welcome a pull request.

Once again, I'm so sorry for the late response.

JoshMcCullough commented 4 years ago

Ran into this as well. IMO the whole point of releasing pre-release packages is to work toward the final release version. It's very, very likely that the final release version will be built from the exact same code as the most recent pre-release version. We wouldn't want to make an unnecessary code change (e.g. add a space or line break) just to promote a pre-release version to release.

And I completely agree with your statement, @vivin ...

I really don't see any downsides to having a release version tag and its corresponding latest pre-release version tag pointing to the same commit. I don't think it should be possible in any other case, though