Pick the most recent chart/tag for ambiguous semver matches #172
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.
As per Semver para 11,
build metadata does not figure into precedence
. This means if two versions have equalMAJOR
,MINOR
,PATCH
tokens, but different build metadata (para 10), the order is 💥 undefined. . Given that we don't simply match version string but chart versions, we have additional metadata, such aschartVersion.Created
, that we can use to further clarify the logic without violating Semver. This behavior also fits the principle of least surprise better.Such a change is useful for dev environments that are expected to get the latest build of the same app/chart. In the current setup, this cannot be done, especially when (and usually does) build metadata contains data that doesn't sort well (git hashes, sigs, etc.).
The same approach applies to GitRepository resources that make use of a semver tag strategy. It is possible to use a timestamp of the tag's target commit: ebfb118
Derived from #171 to decouple this change from migrating to
masterminds/semver
.Related discussion fluxcd/flux2#355
cc @hiddeco @stefanprodan