Ensure semver build metadata is handled appropriately in SortFor{Upgrade,Downgrade}

[sdboyer]

The version sorting funcs separate releases with prerelease versions out into their own category. However, I think they just ignore build metadata right now. This probably isn't right.

[chx]

I will see what can I do.

[chx]

So what are we to do with this metadata? Just sort it lexicographically? if lsv.Equal(rsv) { return lsv.metadata < rsv.metadata; } ?

[sdboyer]

Right, so, what should be done here is a bit of a question. Pulling in the docs on the method for reference:

- All semver versions come first, and sort mostly according to the semver
2.0 spec (as implemented by github.com/Masterminds/semver lib), with one
exception:
- Semver versions with a prerelease are after *all* non-prerelease semver.
Within this subset they are sorted first by their numerical component, then
lexicographically by their prerelease version.
- The default branch(es) is next; the exact semantics of that are specific
to the underlying source.
- All other branches come next, sorted lexicographically.
- All non-semver versions (tags) are next, sorted lexicographically.
- Revisions, if any, are last, sorted lexicographically. Revisions do not
typically appear in version lists, so the only invariant we maintain is
determinism - deeper semantics, like chronology or topology, do not matter.

So yes, within the subgrouping that is "semver with build metadata," we should sort first by proper semver rules, then lexicographically. The question is where that subgrouping should be placed. I can see three possibilities:

1. After the semver-with-prerelease group.
2. After the branch group.
3. Mixed in with normal, metadata-less semver. I think this is what happens now, and is pretty plainly wrong.

I'm torn between the first two. The only argument I can really make, though, is that having the metadata attached to the version effectively strips the semver of much of its meaning, so it's most like non-semver versions. Probably best, then, to go with putting them after the branch group, but before the plain version group.

[fabulous-gopher]

This issue was moved to golang/dep#427