✨ use single semver library #1565
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There are currently two libraries being used directly in the code to deal with semver:
github.com/Masterminds/semver/v3
andgithub.com/blang/semver/v4
.This PR tries to elimitate one of them (blang/semver), since the second library seems to be covering all use cases where blang was being used.
This has a direct impact on security as well as readability and general development, because we won't be needing to deal with different types that ultimately handle the same thing.
At this stage, this is meant to be a draft looking for opinions and any considerations which would explain why this shouldn't be done. I have not looked into masterminds
NewVersion()
vsStrictNewVersion()
for example and if there would be a need to use the latter.Rationale for choosing to go with mastermind's lib in this draft was that we only used two methods from blang that mm covered and used a lot more functionality of mm that blang didin't cover (or at least doesn't seem to cover).
Note: blang/semver still remains as an indirect dependency, potentially because of use in
declcfg
.Reviewer Checklist