Prefix build info with n and h to ensure SemVer 2 validity to solve Helm 3 compatibility

[consideRatio]

Fixes #86 with 14f44dc + test updates.

In short, we now make 0.9.0-alpha.1.095.123asdf become 0.9.0-alpha.1.n095.h123asdf to ensure we never have a numerical identifier with a leading zero, which is breaking Helm 3 usage of our chart because its dependency masterminds/semver now does a better job verifying if the version is a valid semver version etc.

I failed to spot the suggested version with a leading zero in a fully numerical identifier wasn't a valid semver version before =/

This will need a minor version bump for a release, and could once again cause issues from chartpress that @henchc @betatim has helped worked through in the past for binderhub and mybinder.org.

[minrk]

Arg, that's really annoying. These are getting really long, so maybe replace sha with just h for hash? It's not relevant that it's a sha hash, and this is also what conda uses in build strings.

[consideRatio]

Yes, very long, :/

Im afraid of the one letter solution, as that would masquerade it into the hash. Git use g prefix also btw.

Im okay with various options, perhaps even more okay with accepting bad luck can happen and writing out invalid or similar when we get a pure numerical sha starting with zero. I dislike having a single letter the most i think, it made me really confused with the git describe prefixed g for example

[manics]

Consistency is more important than what looks nice. If the value can sometimes be invalid this means no tooling can rely on it's value, in which case you might as well drop it and use something more readable such as a timestamp (with a letter prefix 😀).

I don't think h vs g vs sha makes much difference to the readability since it all gets merged with the hash anyway e.g. shaabc1234 vs habc1234. OTOH given the current proposed string is 29 chars shortening it to 27 isn't that big a saving. Given the length I presume everyone will always copy-and-paste these strings.

Any of h, g, sha, z, sound fine to me, and focus on ensuring correctness so another change isn't necessary.

[minrk]

Yeah, agreed that validity is most important. It’s just frustrating since human intelligibility was the primary motivation that started this whole change, and it’s starting to look a lot less human-friendly in the end. Let’s go with just ‘h’ and release.

[consideRatio]

Anyone wanting to replace the sha prefix with h are welcome to do so by pushing to my branch for this pr. I only have a mobile until 13th jan but i can review changes!

[betatim]

I started replacing sha with h but then realised there are far too many instances to do this via GitHub suggestions, so I stopped :-/

[consideRatio]

Thanks @betatim for the attempt! I'm home now at my computer and stepped through the commits and made a rebased update.

[consideRatio]

I made a 0.6.0 release with this!