Inconsistent release calculation when tag is on current commit

[tinue]

Issue

We know that your time is precious, we are thankful that you take time to report us an issue, to make it easier for you please use the following prefilled paragraphs

version: 1.5.1

usage context:

• [x ] maven command line: 3.6.1

Problem description:

To reproduce. start by creating a repo as outlined in the "Example" section of the readme. Make an initial checkin and commit. Then add a tag with something extra. I used 1.0.0-start. The calculated version will be: 1.0.0-start-SNAPSHOT. Make an additional commit, and check again. This time it's 1.0.0-SNAPSHOT, i.e. the -start part is no longer there.

This is inconsistent and as far I can say, the first one of the calculated versions is incorrect.

TIPD_9 C:\data\Dev\Code\jgitver-tester>mvn validate
[INFO] No suitable configuration file found, using defaults
[INFO] Using jgitver-maven-plugin [1.5.1] (sha1: e45d1669b39cedb98720dd33cc14d0185b455ca1)
[INFO]     version '0.0.0-SNAPSHOT' computed in 2439 ms
[INFO]
[INFO] Scanning for projects...
[INFO] jgitver-maven-plugin is about to change project(s) version(s)
[INFO]     com.example::jgitver-tester::0 -> 0.0.0-SNAPSHOT
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building jgitver-tester 0.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.126 s
[INFO] Finished at: 2019-12-12T09:23:19+01:00
[INFO] Final Memory: 15M/1984M
[INFO] ------------------------------------------------------------------------

TIPD_9 C:\data\Dev\Code\jgitver-tester>git tag 1.0.0-start

TIPD_9 C:\data\Dev\Code\jgitver-tester>mvn validate
[INFO] No suitable configuration file found, using defaults
[INFO] Using jgitver-maven-plugin [1.5.1] (sha1: e45d1669b39cedb98720dd33cc14d0185b455ca1)
[INFO]     version '1.0.0-start-SNAPSHOT' computed in 2623 ms
[INFO]
[INFO] Scanning for projects...
[INFO] jgitver-maven-plugin is about to change project(s) version(s)
[INFO]     com.example::jgitver-tester::0 -> 1.0.0-start-SNAPSHOT
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building jgitver-tester 1.0.0-start-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.311 s
[INFO] Finished at: 2019-12-12T09:23:38+01:00
[INFO] Final Memory: 15M/1984M
[INFO] ------------------------------------------------------------------------

TIPD_9 C:\data\Dev\Code\jgitver-tester>git commit --allow-empty -m "Force new commit"
[master aabe9e1] Force new commit

TIPD_9 C:\data\Dev\Code\jgitver-tester>mvn validate
[INFO] No suitable configuration file found, using defaults
[INFO] Using jgitver-maven-plugin [1.5.1] (sha1: e45d1669b39cedb98720dd33cc14d0185b455ca1)
[INFO]     version '1.0.0-SNAPSHOT' computed in 2851 ms
[INFO]
[INFO] Scanning for projects...
[INFO] jgitver-maven-plugin is about to change project(s) version(s)
[INFO]     com.example::jgitver-tester::0 -> 1.0.0-SNAPSHOT
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building jgitver-tester 1.0.0-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 3.746 s
[INFO] Finished at: 2019-12-12T09:24:51+01:00
[INFO] Final Memory: 15M/1984M
[INFO] ------------------------------------------------------------------------

[McFoggy]

Hi, thanks for reporting.

I see 2 things in your report:

First is that your initial tag is not an annotated tag. Instead of git tag 1.0.0-start do git tag -a 1.0.0-start (recent version of git expect a message for that) In this case the version used (without any further commit) will be the tag itself.

Secondly, the fact that we lose the start qualifier is probably a bug.

[tinue]

In our environment, a lightweight tag creates a SNAPSHOT build, and an annotated tag creates a production build. So, not using -a was intentional. Again for our environment, losing the -start is fine; Keeping it is not ok. But this is up to you of course. As long as it is consistent, we can adapt.

[tinue]

Quick update: When I use an annotated tag, this is what I get:

• Right after adding the tag: version '1.0.0-start' computed in 138 ms
• After one more commit: version '1.0.0-SNAPSHOT' computed in 118 ms

[tinue]

Sorry, one more update. It's very possible that I do not really understand how jgitver works / is supposed to be used. Say one just released a version 1.0. A tag is added, git tag 1.0 -m "Release 1.0" (the -a is implicit here).

Now I want to start with release 1.1.0. I have to add another tag, because jgitver would now calculate 1.0.1.

What I think I should do is this: git tag 1.1.0-start (i.e. lightweight). I can't add 1.1.0, because I need this later for the finished 1.1.0 release. From now on, I'd like the calculated release to be 1.1.0-SNAPSHOT. I might later add lightweight tags such as 1.1.0-RC1. This time, the qualifier needs to be part of the calculated release. Once I want to release, I add the qualified 1.1.0 tag.

Am I completely misunderstanding how this works? I see that you use v to mark the start of a release in your example (v1.1.0); Is this the recommended way?

[McFoggy]

Indeed, if you want to bump the version to something new you have to use a lightweight tag.

2 main possibilities:

• use recognition patterns, by default you can use 'v' as prefix (you can change it it is just a matter of conf). Doing this you can tag with v1.1.0. Later builds will reuse this as base version. Then you can release with an annotated tag 1.1.0.
• use the lightweight tag just as a temporary marker, afterwards delete it and set an annotated tag

[tinue]

Thanks! Both approaches look reasonable. we could also add an empty commit, tag it with -start and then begin the actual release.

Based on my experiments it starts to look like there is no bug In the code. It looks more like outdated or missing documentation. For example this one, from the readme of jgitver: "When the HEAD is on a git commit which contains an annotated tag that matches a version definition, this annotated tag is used to extract the version."

The behavior for lightweight tags does not seem to be documented. Apparently the above is also true for lightweight tags, except that -SNAPSHOT is added in addition.

Also the behavior if HEAD is not on a tag (e.g. section "Maven strategy") seems to be this: The qualifiers are no longer part of the calculated version. This seems to be the case for both annotated and lightweight tags. IMO this makes sense: Usually a qualifier such as RC1 is only valid for the one commit, and not for any later commits.

Is this as intended? If so then I guess my issue can be closed.

[McFoggy]

indeed the issue comes from a not so documented/tested feature which was there to handle RC, beta, alpha versions.

I think I need to further think about this. If you want to give your opinion, do not hesitate.

[tinue]

Thanks! I think I could live with the current implementation, but I would suggest to document this, in order to make it formal.

Possibly some qualifiers could be excluded from ever be a part in a Maven version number, e.g. -start. Maybe such a list of excluded tags could be configurable, with a reasonable default. We only use -start as a qualifier that should never be a part of a version, though.

[soloturn]

@tinue mind creating a pull request towards the readme?

[tinue]

@soloturn Good idea, I might one day; Being a software engineer working in the debit card business, I have more work than ever during this crisis. Time is therefore a bit tight at the moment.