Question: Doubt about the inferred version when changing scope after a tagged RC

[r2edondo]

I'm not sure if that could be an acceptable way to proceed when releasing your software, but technically the following case scenario is achievable.

Plugin configuration info:

org.ajoberstar.release-base version '1.5.1'
versionStrategy FINAL
versionStrategy PRE_RELEASE
defaultVersionStrategy  DEVELOPMENT

Our app just released the v0.1.0

git describe
v0.1.0

Now we execute the following releases:

steps	attributes	published binary	tag
1	scope=patch stage=dev	app-0.1.1-dev.0+39f20aa.jar
2	scope=patch stage=rc	app-0.1.1-rc.1.jar	v0.1.1-rc.1
3	scope=patch stage=dev	app-0.1.1-rc.1.dev.0+39f20aa.jar
4	scope=patch stage=rc	app-0.1.1-rc.2.jar	v0.1.1-rc.2
5	scope=minor stage=dev	app-0.2.0-rc.2.dev.0+39f20aa.jar
6	scope=minor stage=rc	app-0.2.0-rc.1.jar	v0.2.0-rc.1
7	scope=minor stage=dev	app-0.2.0-rc.1.dev.0+39f20aa.jar
8	scope=minor stage=rc	app-0.2.0-rc.2.jar	v0.2.0-rc.2
9	scope=minor stage=dev	app-0.2.0-rc.2.dev.0+39f20aa.jar

In steps 1 to 4 the we are working on a rc 0.1.1, but it never reaches the final stage. At that point (and this could be the non acceptable way to proceed), we decide to change the scope to minor so we will never have a v0.1.1 final release. Because of that, the dev version we get published is the 0.2.0-rc.2.dev.0+39f20aa when I would expect it to be 0.2.0-dev.0+39f20aa.

In the table above I'm working on the same commit, so it's not likely to happen that the published binary have the exact same name as it happens in step 5 and 9, but is confusing anyway.

So, should the version in step 5 be 0.2.0-dev.0+39f20aa?

Thanks,

[ajoberstar]

Yep, looks like a bug.