You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have a need to distinguish between "2" and "2.0" post-parsing, without having to re-parse these strings.
For example, I am writing an automated system to identify when software component versions are no longer supported. The data about support timelines can vary about specificity, so that some products exit support as of a major-wide series 2.x ("2"), whereas other products develop at a much faster rate and can exit support as of particular minor versions ("2.0").
Unfortunately, it appears that semver simply defaults unspecified minor version values, etc. etc. as zero, without providing a clear way to distinguish between an explicit zero input, versus an implicit default of missing information to zero.
I think I may hack around this gap by counting the periods in the original version string prior to parsing with semver. But I would love for a standard feature such as HasMinor(), HasPatch(), HasBuild(), to clarify in a reliable way.
The text was updated successfully, but these errors were encountered:
It's been a little bit since you posted this so may already have a setup that works for this.
When it comes to versions, a missing section is a 0. When an x is used it's a range and that means a constraint. Versions are covered by the semver spec while constraints used for things like ranges are made up by implementers. Some of use try to follow the same patterns.
The way to do all of that with this library is to parse your version as a version (e.g., 2.0.0), create a constraint (e.g., =2.0.0 or 2.x), and then test the version against the constraint.
I have a need to distinguish between "2" and "2.0" post-parsing, without having to re-parse these strings.
For example, I am writing an automated system to identify when software component versions are no longer supported. The data about support timelines can vary about specificity, so that some products exit support as of a major-wide series 2.x ("2"), whereas other products develop at a much faster rate and can exit support as of particular minor versions ("2.0").
Unfortunately, it appears that semver simply defaults unspecified minor version values, etc. etc. as zero, without providing a clear way to distinguish between an explicit zero input, versus an implicit default of missing information to zero.
I think I may hack around this gap by counting the periods in the original version string prior to parsing with semver. But I would love for a standard feature such as HasMinor(), HasPatch(), HasBuild(), to clarify in a reliable way.
The text was updated successfully, but these errors were encountered: