SemanticVersion strips Revision from System.Version - is this known/expected?

[brandonh-msft]

I'm starting to use SemanticVersion to index/parse/process some versions we're getting from DLLs, etc. which are of this format. However, I also have versions which are of the typical System.Version format (major.minor.build.revision) and also see that SemanticVersion has a constructor which takes System.Version in so I thought "great, I'll just centralize around SemanticVersion, then".

To my dismay, however, when you take a System.Version and create a SemanticVersion from it, you completely lose the Revision number. Is this known/expected? I would've at least thought we'd keep it as a Release label, etc.

[zivkan]

@brandonh-msft SemanticVersion, as far as I can tell, is supposed to be a "strict" implementation of Semantic versioning (semver.org), and if you check that spec, it only allows for major.minor.patch (and none of these are optional, like System.Version allows). I'm confident that SemanticVersion.Parse("1.2.3.4") should throw an exception, so it seems like an oversight that the SemanticVersion(System.Version) constructor does not throw when rev != null && rev != 0, but it may be a design bug due to how NuGetVersion extends SemanticVersion.

NuGet has another type, NuGetVersion, which is effectively the superset of all System.Version features plus all Semantic Versioning 2.0 features, so does allow the 4 segment version.

[brandonh-msft]

Perfect, thank you! I'm going to pivot to using NuGetVersion as this is what we're after in our case, but I'm going to leave this discussion open in case it needs to have an issue created from it.