Closed esz closed 6 years ago
Thanks for all of the detail and implementation ideas!
I agree with changing the behavior you see in the tests. As for how to do it, I think there are smaller changes that would get us there:
Reckoner$Builder#stages()
fail if SNAPSHOT_STAGE
is included in the list. Snapshots aren't really valid with other stages given the sorting implications.stage != null && !inventory.isClean()
validation from reckonTargetVersion()
to reckon()
where most of the other validation is. In that location, you could leverage methods on Version
to more cleanly test for this: reckoned.isSignificant() && !inventory.isClean()
.
When building from a dirty repo on a commit tagged with a final release, the behavior of the reckoner is inconsistent when using
snapshotFromProp()
.The following tests (https://github.com/esz/reckon/commit/08ab81d6f092f08e094f203cf149f46c1e067926) reproduce this behavior:
Both tests expect the same result, once supplying the
-Preckon.stage=snapshot
property and once not. IMHO both tests should yield2.1.0-SNAPSHOT
however the second test fails with"Cannot release a final or significant stage without a clean repo."
This behavior is due to
in
org.ajoberstar.reckon.core.Reckoner.reckonTargetVersion(VcsInventory, Version)
This makes perfectly sense when using
stageFromProp()
, since when the user is setting a stage on the CLI this should yield a significant (rc
,milestone
,beta
, whatever..) Version. However, it also causes the inconsistent behavior from above, when using snapshotFromProp()Fixing this by simply excluding "snapshot" in the condition above is not sufficient, since one never knows if we have
stageFromProp('snapshot', ...)
. Please have a look at the changes in https://github.com/esz/reckon/tree/distinguish_between_prerelease_strategies where I attempted to solve this issue.I introduced
org.ajoberstar.reckon.core.Stages
and two implementation which are (or will be) responsible for:Reckoner#stageCalc
function..-rc1.fa7cf732
) of the version string (not implemented yet)