SemanticVersion only supports three part (major.minor.patch) version numbers (plus suffixes); any version number not fitting that format will have a SemanticVersion of null and thus be considered equal.
This commit restores the previous version parsing logic (before #83) as a fallback for when SemanticVersion fails to parse a version number.
I ran into this when displaying packages from a feed that used Windows-style four-part version numbers instead of three-part version numbers. They were all considered to have the same null SemanticVersion and appeared unordered in the UI.
As per 1c63a21d8f55df79e2022c885dc21b2a394afded there must previously have been packages with four-part version numbers (since the code was extended to handle them); this PR reinstates support for packages versioned that way (while still preferring to compare packages by SemanticVersion).
This also fixes a minor bug where PackageVersion.CompareTo didn't handle a null argument correctly. (All non-null objects should be "greater than" null.)
SemanticVersion
only supports three part (major.minor.patch) version numbers (plus suffixes); any version number not fitting that format will have aSemanticVersion
ofnull
and thus be considered equal.This commit restores the previous version parsing logic (before #83) as a fallback for when
SemanticVersion
fails to parse a version number.I ran into this when displaying packages from a feed that used Windows-style four-part version numbers instead of three-part version numbers. They were all considered to have the same
null
SemanticVersion and appeared unordered in the UI.As per 1c63a21d8f55df79e2022c885dc21b2a394afded there must previously have been packages with four-part version numbers (since the code was extended to handle them); this PR reinstates support for packages versioned that way (while still preferring to compare packages by
SemanticVersion
).This also fixes a minor bug where
PackageVersion.CompareTo
didn't handle anull
argument correctly. (All non-null objects should be "greater than"null
.)