More flexibility in versionCode generator

[xen0n]

As the source code shows, currently the versionCode generator discards any character not a digit or period in version name. This would, for example, fail when faced with a git describe-formatted version name as generated by the git-commit-id-plugin. AFAIK this could not be solved without forking either plugin or changing the versioning scheme.

We can possibly allow configuration of version part separator characters, so that these use cases are covered.

[xen0n]

Example:

Consider this version name 0.0-38-g493f883 (yes, that's for a prototype app). Under the current implementation, the latter git describe parts cannot be removed in any way, so one can only:

• ignore the last part of version altogether (not really acceptable), or
• be prepared to deal with a 8-digit-minimal and ever-changing version part (not elegant).

PS: I can prepare a pull request for my suggestion above; before I begin I'd like to hear any comments or alternative approaches (if considered more suitable).

[william-ferguson-au]

You're talking about the VersionGenerator class used by the ManifestMergerMojo and ManifestUpdateMojo for generating a version for the AndroidManifest?

I'm all for making the code more versatile.

What did you have in mind to replace the existing implementation?
And what output would you expect for your input example of 0.0-38-g493f883?
Probably a good idea to provide a table of scenarios and the expected output.

[xen0n]

As my own use case is directly taking the output of git describe (as produced by the git-commit-id-plugin) as manifestVersionName, at least I would expect the VersionGenerator to elegantly deal with version names formatted as such. It boils down to making the separation of version parts configurable:

• Either split by different characters,
• or (arguably better but more complex) allow using regex to extract individual parts.

In this case (0.0-38-g493f883), one would configure the plugin like this:

<manifestVersionCodeUpdateFromVersion>true</manifestVersionCodeUpdateFromVersion>
<manifestVersionDigits>4,3,3</manifestVersionDigits>

<!-- added configuration -->
<manifestVersionSeparators>.-</manifestVersionSeparators>

<manifestVersionName>0.0-38-g493f883</manifestVersionName>

and expect a versionCode of 38 (0000,000,038 actually, the version name is a little bit pathetic, but you get it.)

If a regex-based approach is taken, one would instead write something like:

<!-- only match the interesting parts -->
<!-- I just made this tag name up; it definitely can be made shorter... -->
<manifestVersionNamingPattern>^(\d+)\.(\d+)-(\d+)</manifestVersionNamingPattern>

<!-- or even like this (just imagining the possibilities here), note the reordering enabled by using named groups: -->
<manifestVersionNamingPattern>^(?P&lt;1&gt;\d+)\.(?P&lt;3&gt;\d+)-(?P&lt;2&gt;\d+)</manifestVersionNamingPattern>

This has the downside of requiring one to specify a regex and actually sticking with that, but in reality regexes are ubiquitous; also, if one actually finds him/herself having to do manifest magic like this, probably a simpler functionality would not be sufficient.

Anyway here are some example version names taken from my phone, in addition to the git describe-formatted one:

• 2.0-beta-2015-03-05 (Wikipedia Beta)
• 5.0.1 (1642443) (Gmail)
• 6.1.0.66-r1062275 (Wechat)

None of these can be correctly processed by the plugin at present; the simpler first approach can somehow deal with them, albeit by ignoring irrelevant characters; the regex approach can handle them elegantly.

Now which approach would people prefer? (Personally I would go regex.)

// EDIT: Ouch, the angular brackets in named group syntax should be escaped. Maybe that's a good sign indicating that this degree of versatility is unnecessary...)

[william-ferguson-au]

I favour regex.

But we need the default to match the existing default implementation so
that we don't break anyone.
And we need to fallback to current impl if someone has configured for
current impl and the new impl can't consume the old config (a warning to
upgrade is also recommended).
ᐧ

On Tue, Mar 10, 2015 at 1:25 AM, Wang Xuerui [email protected]
wrote:

As my own use case is directly taking the output of git describe (as
produced by the git-commit-id-plugin
https://github.com/ktoso/maven-git-commit-id-plugin) as
manifestVersionName, at least I would expect the VersionGenerator to
elegantly deal with version names formatted as such. It boils down to making
the separation of version parts configurable:

• Either split by different characters,
• or (arguably better but more complex) allow using regex to extract
  individual parts.

In this case (0.0-38-g493f883), one would configure the plugin like this:

true
4,3,3

.-

0.0-38-g493f883

and expect a versionCode of 38 (0000,000,038 actually, the version name
is a little bit pathetic, but you get it.)

If a regex-based approach is taken, one would instead write something like:

^(\d+).(\d+)-(\d+)

^(?P<1>\d+).(?P<3>\d+)-(?P<2>\d+)

This has the downside of requiring one to specify a regex and actually
sticking with that, but in reality regexes are ubiquitous; also, if one
actually finds him/herself having to do manifest magic like this, probably
a simpler functionality would not be sufficient.

Anyway here are some example version names taken from my phone, in
addition to the git describe-formatted one:

• 2.0-beta-2015-03-05 (Wikipedia Beta)
• 5.0.1 (1642443) (Gmail)
• 6.1.0.66-r1062275 (Wechat)

None of these can be correctly processed by the plugin at present; the
simpler first approach can somehow deal with them, albeit by ignoring
irrelevant characters; the regex approach can handle them elegantly.

Now which approach would people prefer? (Personally I would go regex.)

—
Reply to this email directly or view it on GitHub
#605 (comment)
.