Skip to content
This repository has been archived by the owner on Oct 5, 2018. It is now read-only.

Why bumping by +1? #174

Closed
javajon opened this issue May 4, 2016 · 5 comments
Closed

Why bumping by +1? #174

javajon opened this issue May 4, 2016 · 5 comments
Labels

Comments

@javajon
Copy link

javajon commented May 4, 2016

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?

@ajoberstar
Copy link
Owner

Most likely you have uncommitted changes in your repo. The release plugins will only reuse a tagged version if there are no changes.

@javajon
Copy link
Author

javajon commented May 6, 2016

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?

@ajoberstar
Copy link
Owner

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:

println grgit.status()

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.

@ajoberstar
Copy link
Owner

Once you get past the uncommitted changes, it should infer 1.0.0 as your version since you're on the tag. No need to run the release task or pass in any properties.

@ajoberstar
Copy link
Owner

Feel free to reopen if this didn't resolve your issue.

# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants