search

ajoberstar / gradle-git

Git plugin for Gradle
Apache License 2.0
561 stars 89 forks source link

Need to use highest version, not nearest #262

Closed MartinDevi closed 7 years ago

MartinDevi commented 7 years ago

Hi,

Thanks for all your work on this project.

I recently ran into an issue with the way that the nearest version, which is incremented in order to generate the current one, is selected. Currently, NearestVersionLocator walks the history to find the tagged versions and chooses the nearest one.

In my use case, I have to maintain several major releases, so I keep a branch for each one. So for example, if I just released my version 4, then I'll fork a v5 branch from v4 for the next release in development. I'll launch gradle-git a first time v5 to increment the major version, generating a 5.0.0 tag. From this point, all the commits on the v4 branch will have tags with major version 4 and below, while commits on the v5 branch will have tags with major version 5 and below. And I'd like all the new tagged versions generated by gradle-git on v5 to have 5 as their major version.

This was working fine until recently, when we ran into a scenario where gradle-git started generating tags with major version 4 on the v5 branch. This is because we regularly merge the v4 branch into v5, to get the latest fixes. In this particular case, there were more fixes done on v4 than there were developments pushed on v5, therefore the distance to the latest tag on v4 was less than the one to the latest tag on v5. The situation eventually stabilized once we manually fixed the tags on v5, and once enough developments had been pushed. But this is an issue that we are likely to encounter every time we release a new major version.

The solution seems to be an option to choose differently the nearest ancestor from which the version is inferred. This way, NearestVersionLocator could be configured to use the parent with the highest version, not the one with the least distance.

I'll submit a pull request shortly to provide this option.

MartinDevi commented 7 years ago

Created the PR. Let me know if you're OK with the API enhancement, so that I can complete it with documentation.

ajoberstar commented 7 years ago

Hi Martin, thanks for raising this. The max version in the history of the current commit is a more accurate way to cover most situations, and is also the approach I'm taking in reckon, which is meant to replace the versioning logic in gradle-git. Once I get the documentation written, I think it's ready for people to use (though I don't have an ETA for that).

I am in the process of breaking up gradle-git, so that each plugin is in it's own repo. The publishing and versioning ones are being entirely re-written. In the meantime, I won't be adding new features to gradle-git; it will just be minor maintenance.

Given that, I won't be merging in your PR. I believe reckon will meet your use case, so I hope that will soon be a good option for you to switch to. Thanks for your interest in contributing!