Pattern ${meta.PATCH_PLUS_COMMIT_DISTANCE}

[Brixomatic]

Say I have a version tagged as 1.0.7
Say I have 2 commits on top of that version.

With ${M}.${m}.${p} and "autoIncrementPatch", I could get was version 1.0.8
Using ${M}.${m}.${meta.COMMIT_DISTANCE} I would get version 1.0.2, which doesn't make sense.

It would be nice to have a version pattern like:
${M}.${m}.${meta.PATCH_PLUS_COMMIT_DISTANCE} effectively giving me version 1.0.9
That would respect both the latest patch version of the tag and the commit distance as an increment.

[McFoggy]

why do you want to add COMMIT_DISTANCE to the patch level?

[Brixomatic]

Long story, but it begins with the jpackage not accepting other version numbers than {M].{m}.{p} on Windows (for some other limitations of installation tools used).
This means, any "-1" or any "-SNAPSHOT" or commit-ID in version numbers will fail the build.
As a result, if I want most commits to be a version, I need to increase the version number with every commit.
I could do that by setting loads of tags, then I wouldn't need jgitver.

If I used "auto increase" all commits would add up to the next patch version, until a new tag was set. A valid scheme, but then If I have a lot of patch releases, I'm back to setting loads of tags.
If I used the commit distance as patch level and used only a major+minor version in tags that would work, but then I can't use any patch level in a tag (e.g. to mark a version that is noteworthy or to correct the patch level for a change in a readme that doesn't change the code), because that patch level is swallowed and every tag acts as a reset for the commit distance and I end up in the example above, where a newer commit has a lower patch level than an earlier commit, which messes up the versioning scheme.
So, today patch levels and commit distances don't play together nicely.

With this pattern, one could tag any version (including patch) and have an automatic increase that has the latest patch as baseline and sees any additional commit as a patch on top of that.
Plus, I hope, it should be rather easy to implement.

[Brixomatic]

I've created a PR:
#148