Clarify versioning and tagged release process #359
Conversation
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
Signed-off-by: Marcela Melara <[email protected]>
| ### Examples | ||
|
|
||
| - Attestation Framework tagged release v1.0.2 (PATCH version) incorporates | ||
| refinements to the predicate specification process, a new predicate type, |
There was a problem hiding this comment.
IMO it is a bit confusing for semantic versioning of the spec to not apply to predicate changes (which I agree with) while also saying a spec version ships with a new predicate. Maybe the version of the spec should entirely omit predicates and it's just a matter of convenience that predicates live alongside the spec?
This does get a bit confusing with versioning of the code gen libraries though, as you highlight here.
There was a problem hiding this comment.
I see what you mean. The intent here isn't to say that none of the things under the PATCH version category really affect the core spec. Maybe we can take out the mention of predicate types altogether and say that PATCH versions are only for doc edits and language binding changes?
There was a problem hiding this comment.
I think that might be better!
There was a problem hiding this comment.
I also realized that language bindings are going to be fine; breaking changes in a predicate would be effectively a separate model with its own proto from the previous one.
This PR adds a short description clarifying when the attestation spec version is rev'd and how that relates to tagged releases.