Version not calculated correctly from release candidates about nebula-release-plugin HOT 7 CLOSED

Hmm, I was confused by the answer of @rspieldenner .

I would expect a candidate producing 2.1.0-rc.2

That is actually the case right? Because, if you print the project version during a candidate build, using

task('version') << {
  println ('VERSION: ' + project.version)
}
tasks.version.dependsOn project.tasks.prepare

and ./gradlew candidate version you get 2.1.0-rc.2. Also, running ./gradlew candidate and then ./gradlew -Prelease.useLastTag=true version will produce the same.

Removing "dev" from

2.1.0-rc.2.dev.0+0faf0e7 instead of 2.1.0-rc.2.0+0faf0e7

doesn't do much I would say. You're developing on the release candidate, which is perfectly valid - otherwise you would have done a final release. I would definitely not fail the build until ./gradlew final is called, because you might want to have people test these final bugfixes you're working on. Nor would I advance to the next version, because you are working towards the final 2.1.0 release. @rspieldenner may have a point in saying you could change rc.2.dev.... to dev.... again, but the former does make clear you're working on a release candidate to create the final release.

from nebula-release-plugin.

I would expect a candidate producing 2.1.0-rc.2 and then a devSnapshot would return to 2.1.0-dev.#+hash

from nebula-release-plugin.

You can get this to work with https://github.com/nebula-plugins/nebula-release-plugin#releasing-using-last-tag

My workflow (see https://github.com/stackwork/stackwork for sources) is that I run ./gradlew candidate locally, which pushes a git tag to my repository. Then (and you could of course also do this locally), the build script run by Travis does ./gradlew -Prelease.useLastTag=true candidate publishPlugins, resulting in the expected release.

EDIT: but you know this of course - better answer below

from nebula-release-plugin.

One thing to keep in mind is that Gradle will sort

1.0.0-dev.3... < 1.0.0-rc.2.dev.3... < 1.0.0-rc.2

Gradle explicitly enforces that dev < rc, and adding any non-numeric tag is less than not adding a non-numeric tag. (It's documented in JavaDoc.)

So, it would be very handy for local development if devSnapshot on a candidate tag produced something like 1.0.0-rc.2.3... or something like that. That way, local development can continue between release candidates, and Gradle will resolve versions in a sane manner.

Advancing to the next version, i.e., 1.1.0-dev..., would also be sane-ish, but it would sort higher than all release candidates, which might be surprising.

I just saw that this issue is several years old at this point. I hope something can be done about this, because the current ordering is confusing for local development with release candidates.

from nebula-release-plugin.

Are there any plans to address this issue? I've run into it again today trying to do local development off a release candidate. The Gradle version ordering is not going to change, so this really is a bug.

from nebula-release-plugin.

This should be fixed now in 12.0.0.

More details in https://github.com/nebula-plugins/nebula-release-plugin/pulls?q=is%3Apr+is%3Aclosed

from nebula-release-plugin.

It seems #162 does not really cover what @nadavc originally asked for. As pointed out by @chrisbouchard, gradle always prioritize rc version, so ideally, the version needs to be bumped when a RC is cut so that current development can continue.

I think what needs to be done is that when calculating the next dev version, nebula plugin needs to not only look at the latest release version but also the latest RC version.

For an example:
latest release version tag: v1.0.0
latest rc version tag: v1.1.0-RC.1
the next dev version with minor as release.scope should be: v1.2.0-dev

from nebula-release-plugin.