tschulte/gradle-semantic-release-plugin

Versions don't appear to increment at all

Opened this issue · 3 comments

TimothyJones commented

No matter what I do, I can't seem to get the versions to increment. Perhaps I am using the plugin wrong?

Here's a simple way to replicate it:

git clone git@github.com:tschulte/gradle-semantic-release-plugin.git

cd gradle-semantic-release-plugin
git checkout -b semver
./gradlew

(at this point, the inferred version should be something like 1.3.2-semver-SNAPSHOT)

touch somefile
git add -A 
git commit -m "feat: illustrate the problem"
./gradlew

observe that the version is still 1.3.2-semver-SNAPSHOT, but I think it should be 1.3.3.

error418 commented

By default version increments only happen when following conditions are met:

  • No unstaged files in repository
  • Current branch is master or release branch

Try using a release branch or master - you find everything you need to know in the docs (This behavior can also be customized)

edit: Here's the link to the mentioned documentation section

tschulte commented

In addition to what @error418 said. When I try to reproduce your issue, I get:

  • git describe: v1.3.1 (HEAD at last released version v1.3.1)
  • inferred version: 1.3.2-SNAPSHOT
  • after commit "feat: ..." on master: inferred version 1.4.0-SNAPSHOT
  • after commit "feat: ...\nBREAKING CHANGE: ...": inferred version 2.0.0-SNAPSHOT
  • on dev-branches the above inferred versions also contain the branch name

The -SNAPSHOT is only removed, when you actually release (which should be done by the CI server only).

I'd like to close this issue. Is this OK with you?

If you still have issues, feel free to ask.

TimothyJones commented

I'll send a documentation update PR when I get it working - in particular, I found this part misleading:

Is there a way to preview which version would currently get published?
If you run ./gradlew locally, the version that would be build gets logged (just remove -SNAPSHOT).

I also couldn't get the versions to increment on a branch named release/1.0.0, but after unpacking the regular expression, I see I should have named it release/1.0.x. Whichever is correct, I'm confused by having to name even partial versions in the release branch - isn't the point of this plugin not to have to know what the version is?

I think the documentation could be improved to make the expectations clearer, but I'm not able to do this while I'm still not sure how it is supposed to work.

The section linked by @error418 mentions Travis - does that mean this plugin only works with Travis?

@tschulte I think this issue highlights some important documentation improvements - perhaps it should be renamed instead of closed?

Other questions that are not clear from the readme:

  • What permissions the github token needs
  • Whether the plugin can be used without the github token
  • That feature branches never get their own version numbers (I think?). Seems like they get the currently-released master version number, plus the branch name. I'm fine with this behaviour, but I think it could be make clearer.
  • The difference between version numbers and releases (if any?)