search

ajoberstar / reckon

Infer a project's version from your Git repository.
Apache License 2.0
185 stars 28 forks source link

Gradle is preferring a milestone to a final release #114

Closed cpw closed 4 years ago

cpw commented 5 years ago

I have been using reckon for a while to manage all the minor forge projects. They're all configured the same way. Today I noticed that gradle is preferring eventbus-0.10.0-milestone.0.1+bc511e3.jar to a newer jar eventbus-0.10.0.jar

This came about because my co-conspirator failed to tag the release as a patch (it should have been eventbus-0.9.4.jar). It seems reckon has gotten completely confused about what the next version in the sequence should be, and I don't know how to fix it.

It seems I can get the behaviour I want by tagging all builds on the Jenkins with -Preckon.scope=patch (so any untagged commits it sees it will always consider a patch, rather than a minor) but how do I get that to be the default preference? I don't see any documentation on defaulting it.

I would also point out that your statement in the readme is incorrect now: NOTE: This approach is tuned to ensure it sorts correctly both with SemVer rules and Gradle's built in version sorting (which are subtly different).? It certainly seems that it's not sorted the correct fashion - see above - the final minor is not being preferred to the milestone.

ajoberstar commented 5 years ago

Hi @cpw, I may not be following, but it seems like there are a couple different issues interwoven in here.

When you say Gradle prefers 0.10.0-milestone.0.1+bc511e3 to 0.10.0, do you mean that you have both of those versions published to a Maven repository and a latest.release (or similar dynamic version) dependency on eventbus is pulling down the milestone instead of the final?

The aspect about defaulting the scope, it's correct that there's no way to modify the default. You can do something like (not sure if this is the exact method) if (!project.findProperty('reckon.scope')) { project.ext.['reckon.scope'] = 'patch' }.

Regarding the readme statement's correctness it depends on whether you're seeing this happen with Reckon inferring the version or with Gradle resolving versions from Maven repositories. The latter is what the version scheme was tuned for, so that both Gradle and SemVer consider the versions to be in the same order.

If my questions so far seem to be missing the mark, could you provide some more context about the specific steps you followed to encounter the issue or provide a reproducible sample?

cpw commented 4 years ago

Closing. It hasn't occurred since. I'll open an issue about default scope selection separately.