-
Notifications
You must be signed in to change notification settings - Fork 89
Why bumping by +1? #174
Comments
Most likely you have uncommitted changes in your repo. The release plugins will only reuse a tagged version if there are no changes. |
OK, thank you. I now understand why it's like that. Given this how could one start a project with version 1.0.0? It appears it must be tagged with 1.0.0 and the first release at minimum would have to be 1.0.1, with the opinion plugin. Also, after push of code with a v1.0.0 tag our Jenkins job with the command "gradlew clean publishArtifactory" publishes the jar artifact with version 1.0.1-dev.1.uncommitted+c406341. Notice the tag is 1.0.0 and there are no uncommitted changes yet version is 1.0.1. Perhaps because the "release" task was not specified? Do you recommend on our Jenkin job we instead use: ./gradlew release -Prelease.scope=patch -Prelease.stage=final This means each time the patch # would get bumped and pushed? If this is not right could you lay out some suggested or typical steps for workflow for a developer and a CI server? |
While the C Git may not report any changes, JGit (used by Grgit and thus gradle-git) doesn't always match that exactly. To find out what it thinks is changed, you can print out the status object:
It could be related to submodules if you use those. There are other issues ajoberstar/grgit#80 and ajoberstar/grgit#60 that are tracking that problem. |
Once you get past the uncommitted changes, it should infer |
Feel free to reopen if this didn't resolve your issue. |
Experimenting with both org.ajoberstar.release-base and rg.ajoberstar.release-opinion. The build task is building my jar as expected from the git tag v1.0.0. However, given the tag is v1.0.0 I would expect the jar to be foo-1.0.0.jar. Instead, the patch number is bumped by one as foo-1.0.1.jar
Through tagging how would I ensure a 1.0.0 jar gets created and released?
The text was updated successfully, but these errors were encountered: