search

vivin / gradle-semantic-build-versioning

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

`startingVersion` property not respected in the `semantic-build-versioning.gradle` file #91

Closed GrayCatCode closed 6 years ago

GrayCatCode commented 6 years ago

I inherited a Gradle plugin project from a previous developer that used a much older ('1.1.3') version of the plugin, and I just updated the project to use version 4.0.0. There were two tags on the plugin project ('0.1.0' and '0.2.0') when I pulled it from Git (with '0.2.0' being the tag on the version I checked out) and I haven't checked in any of my changes as of yet. I'm running Gradle v4.0.2 and Java v1.8.0_121 64-bit on a Linux machine.

When I run a clean build, the version on the plugin JAR is set to '0.1.1'.

If I run a build with the -PbumpComponent=minor property set, the version of the JAR is bumped to '0.2.0' as you would expect.

If I run a build with the PbumpComponent=major property set, the version of the JAR is bumped to '1.0.0' as you'd also expect.

My semantic-build-versioning.gradle file is empty, but if I set the startingVersion property in the file (say to '0.2.0' or '1.0.0') it doesn't seem to be respected at all. I would expect that setting the startingVersion property in that file would override any tags set on the project in Git or any other properties but it doesn't seem to work that way; is that correct or am I misunderstanding how the current version is computed?

Many thanks in advance!

vivin commented 6 years ago

I would expect that setting the startingVersion property in that file would override any tags set on the project in Git or any other properties but it doesn't seem to work that way; is that correct or am I misunderstanding how the current version is computed?

The startingVersion is used to set the initial version if no previous versions can be found. This usually happens when you are using the plugin on a project that doesn't have any existing tags. So the behavior you're seeing is expected, since you already have existing tags.

The default value is 0.1.0, but you can set it to whatever you want (maybe you have a project that already has released artifacts but no tags, and so you want to set the starting version as the next actual version instead of the default).

However, I'm curious why you're seeing 0.1.1 and 0.2.0 -- if the latest tag is 0.2.0, then I would expect to see 0.2.1 (on clean build) and 0.3.0 (on -PbumpComponent=minor). Is HEAD on the 0.2.0 tag?

GrayCatCode commented 6 years ago

However, I'm curious why you're seeing 0.1.1 and 0.2.0 -- if the latest tag is 0.2.0, then I would expect to see 0.2.1 (on clean build) and 0.3.0 (on -PbumpComponent=minor). Is HEAD on the 0.2.0 tag?

You would be quite correct sir; as it turns out HEAD is on the version that I checked out which is tagged 0.1.0. There was work done in the repo and a 0.2.0 tag put on the last change but HEAD and master remained on the previous 0.1.0 tag.

vivin commented 6 years ago

Ok, then that makes sense. I thought there might have been a bug. :)

Did my explanation address your issue?

GrayCatCode commented 6 years ago

Ok, then that makes sense. I thought there might have been a bug. :)

So did I. ;) You were spot on; I'm new to Gradle and the plugin so it's quite the learning experience. I thank you for your patience and explanation. :) I'll close out the issue.