indifferent behaviour between rc, milestones and final stages

[childnode]

It's clear to me, that rc or milestones are not relevant if you are on a tagged commit. but it's even unclear to me, why then final stage should become interesting and is increased?

bash:$ git describe
0.0.1

bash:$ ./gradlew build -Preckon.scope=minor -Preckon.stage=final

> Configure project : 
Reckoned version: 0.1.0

bash:$ ./gradlew build -Preckon.scope=patch -Preckon.stage=milestone

> Configure project : 
Reckoned version: 0.0.1

bash:$ ./gradlew build -Preckon.scope=patch -Preckon.stage=rc

> Configure project : 
Reckoned version: 0.0.1

expected

bash:$ git describe
0.0.1

bash:$ ./gradlew build -Preckon.scope=minor -Preckon.stage=final

> Configure project : 
Reckoned version: 0.0.1

[ajoberstar]

In your examples, you use a scope of minor for the final stage, but use patch for milestone and rc. I think that's the cause of the difference you see.

If you pass empty strings or just don't add the properties at all, it will leave the version as is if the commit is already tagged.

But maybe I'm not following your desired behavior.

[childnode]

ohm .. sorry @ajoberstar

1. for the "delay"
2. for the bad example BUT even, the inconsistency is still there

   
   bash:$ git describe
   0.0.1

bash:$ ./gradlew build -Preckon.scope=patch -Preckon.stage=final

Configure project : Reckoned version: 0.0.2

while rc or milestone resolve to tagged `0.0.1`

another way round, even -Preckon.scope=minor -Preckon.stage=rc and -Preckon.scope=minor -Preckon.stage=milestone are 0.0.1 while final bumps to 0.1.0 as shown above

so, is there a reason for this "final" is handled differently on tagged commits?

[ajoberstar]

Reckon tries to determine if you intend to "rebuild" the tagged commit. Usually this is determined by whether you provide input or not via the properties. If it's a tagged pre-release, you have more flexibility. If it's a tagged final version, it only lets you re-release it as another final version. It's mostly an intention to not allow potentially "invalid" increases in the version. In some cases they might be too restrictive.

Which version are you on? The rebuild behavior was rewritten recently. Off the top of my head, I'm thinking that providing input (via properties) should prevent it from doing a rebuild (ideally failing).

[childnode]

hi andrew,

yes indeed, I was on some old stuff hanging around, your "rebuild" behaviour now rejects re-releasing tagged finals other than final. these new build failure indications with your explanations made this clear.

thank you