Document or resolve git metadata when attached to versions

[padraic]

In certain scenarios, a version can be injected into PHARs which is of the form: 1.0.0-26-gh378sj7.

The first part is a recognisable version number. The second part is the number of commits that the referenced build is ahead of the 1.0.0 tag by. The third part, prefixed with a g is the current commit hash.

The current solution (see #34) is to simple strip out the metadata, i.e. you end up with 1.0.0 as the normalised version. Clearly, that is not the correct answer. The correct answer is that this is a pre-release version not even marked alpha (i.e. it's 26 commits ahead of the actual 1.0.0). This tends to show up where versions are automated via box.

Solutions?

1. Inject pre-release marker if not already present (we can easily check if a pre-release label, like alpha is already attached). Probably use -dev if none already present: 1.0.0-26-gh378sj7 becomes 1.0.0-dev.26-gh378sj7
2. Strip the commit hash as useless information: 1.0.0-dev.26-gh378sj7 becomes 1.0.0-dev.26
3. Check if the revised version can be evaluation by Composer\Semver, and properly compared.

Other solution? Report to Composer? I'm really not feeling this as being their problem though. Under Semver, one would expect metadata to be attached using a + sign. It's not!

Report to Box? That's more realistic, but they may have entirely alternative reasons for why this is valid.

[aik099]

Ha, that's almost what I did in my custom strategy (see https://github.com/console-helpers/svn-buddy/blob/master/src/SVNBuddy/Updater/Updater.php#L25-L50):

1. explode version by - (version according to semver, commit count after that version, git commit hash)
2. compare version (1st part) according to semver and if they don't match return early
3. if version according to semer match, then version with larger commit count after that version wins