Proposal: @ytt:semver
#539
Conversation
mamachanko
force-pushed
the
proposal-ytt-semver
branch
2 times, most recently
from
54b1cdf to
ad11f05
Compare
proposals/ytt/005-semver/README.md
Outdated
| * There's a host of conceivable additional operations available for semver, e.g. test against range, sort list of | ||
| versions, bumping, etc. It is debatable if that should be part of the standard library. Testing against a range and | ||
| sorting are likelier candidates for a standard library. Bumping is possible with the primitives presented. |
There was a problem hiding this comment.
One solid data point for validating absorbing logic like this is that it already exists. Having examples of these in hand not only provide great use cases, they also can help steer questions of scope like this one.
What custom code have configuration authors already written? (and I'm thinking about other systems as well: Helm chart templating, CUE libs, etc...
There was a problem hiding this comment.
One solid data point for validating absorbing logic like this is that it already exists.
Cool! I read this as "consider extending the proposal with sorting, range tests and modifications". Am I right?
Having examples of these in hand not only provide great use cases, they also can help steer questions of scope like this one.
In other words, you are saying "find data, act on it", aren't you?
proposals/ytt/005-semver/README.md
Outdated
| #@ d.update(major=d["major"]+1) | ||
| #@ next_major = semver.version(**d) |
There was a problem hiding this comment.
Interesting to propose keeping modifications outside of the semver API, itself. It certainly keeps things simpler language-wise. But I also wonder how frequently version modification (will) occur in templated configuration. 🤔
There was a problem hiding this comment.
I held back on modifications, because the spec only defines bumping major, minor and patch versions. What would be the next prerelease? Some tools like semantic release have opinions.
However, it would still be interesting to explore modifications in the API. It would help the discussion too I think, when there's something concrete to talk about. I will amend the proposal.
| * Education around and proliferation of the semver scheme is not considered to be `ytt`'s responsibility. | ||
|
|
||
| ### Specification / Use Cases | ||
|
|
There was a problem hiding this comment.
TODO: fold in any new use case / needs from Package Version Constraints in kapp-controller
mamachanko
force-pushed
the
proposal-ytt-semver
branch
2 times, most recently
from
67408a6 to
f9e68a5
Compare
|
within vendir and kapp-controller we needed a way to deterministically sort semvers even if they are "equal" according to spec (e.g. version is same but buildmeta is different). we did create a fork of blang/semver, stored in https://github.com/k14s/semver/, to impl deterministic sorting. i would recommend to use this impl within ytt as well to provide similar deterministic behaviour. (even though technically it's against semver 2.0 spec). |
@cppforlife Which branch/commit? there are three branches. |
mamachanko
force-pushed
the
proposal-ytt-semver
branch
2 times, most recently
from
67a8aa0 to
7e0911c
Compare
mamachanko
force-pushed
the
proposal-ytt-semver
branch
from
7e0911c to
ab2c40e
Compare
|
@pivotaljohn I iterated on the proposal, consolidated (hopefully representative and not too fantastic) use cases, improved bits and bops and beautify'd. @cppforlife Your suggestion to use |
Co-Authored-by: Varsha Munishwar <[email protected]>
Co-Authored-by: Varsha Munishwar <[email protected]>
Following discussions with [gcheadle-vmware](carvel-dev/ytt#604 (comment)) and @cppforlife, it became clear that @assert/validate ought to always be consumed in a step after overlays are applied for the current pipeline. When writing schema, the author intends not for the schema document _itself_ to be validated, but to validate the _produced_ document (of which the schema is a basis for). Authors need a way to declare the intention for a validation to be attached to the type composite: @schema/validation.
The former is a predicate (expected to return True or False), the later is an assertion.
It seems quite likely that we'll need such a facility for more advanced cases. Placed in the "Other approaches considered" means that the ideas are found without sufficient merit; not the case here.
(from conversation with @vrabbi; that you Scott!)
Identified as redundant as described in carvel-dev/ytt#732.
Signed-off-by: Joao Pereira <[email protected]>
- Add Joao as a Lead for `imgpkg` Signed-off-by: Joao Pereira <[email protected]>
Signed-off-by: Joao Pereira <[email protected]>
Thanks to the encouragement of @jtigger, I would like to propose that
ytt's standard library offers support for semver.This was initially inspired by carvel-dev/ytt#705
🔗 Carvel's proposal process
todo