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
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,