Leaf: Clarify the prerelease-flag #75
Conversation
Close CycloneDX#44 Signed-off-by: Olle E. Johansson <[email protected]>
|
Ping @vpetersson |
tea-leaf/tea-leaf.md
Outdated
| The Prerelease flag is used to indicate that this is not a final release. For a given Leaf with a UUID, the flag | ||
| can be set to indicate a "test", "beta", "alfa" or similar non-deployed release. It can only be set when |
There was a problem hiding this comment.
Should we stress the fact that this applies to non-deployed releases, regardless of the naming.
For example org.apache.logging.log4j:log4j-core:3.0.0-beta3 does not count as pre-release, since we are not allowed by Maven Central to modify it.
There was a problem hiding this comment.
I would definitely set something named "-beta3" as a prerelease. If you modify something, that's always a new release with a new leaf. Maybe we need to be clearer in the text.
The thing with the flag change was that in some cases a pre-release is upgraded to final release after testing, without ANY changes. That's just another release behaviour.
There was a problem hiding this comment.
The concept of "pre-release" will mean different things to different parties:
- Maven: As per example from @ppkarwasz - it was published; it cannot be modified; it is not intended for use in Production systems
- COTS: E.g. Windows Server 3030 RC (fictitious) - it was published; it cannot be modified; it is not intended for use in Production systems
For me both these examples would be considered as pre-releases by their Manufacturers.
There was a problem hiding this comment.
We have had long discussions about this before, but can of course restart if needed.
There was a problem hiding this comment.
My only point really is that our definition is not clear in the docs we have. Not that it hasn't been discussed already 😉
There was a problem hiding this comment.
Some thoughts on this:
- We need to be dynamic here -- in some workflows per-releases will not be published, but in other workflows they will (e.g. promoted). Thus, as long as we allow for
PATCHing the LEAF to toggle this boolean, we should be good and cover both workflows. - NIT:
s/alfa/alpha/gands/prerelease/pre-release/g
There was a problem hiding this comment.
Does everyone agree with @vpetersson's conclusion? Does that work for you @ppkarwasz?
I think we still need to add wording to clarify in Docs.
There was a problem hiding this comment.
Seems like we have a conclusion. What text is needed to clarify more? I tried to be bit fuzzy in the text to not hardcode to a specific example. The flag is meant as a warning to not use this release. We can rename it to "not-recommended" or something along those lines to avoid the discussions about all variants of "beta", "pre-release", "test-release" etc. Just have a marker that the vendor do not recommend using this in production.
We will need a similar flag for when a release is considered dangerous because it contains a vulnerability that's fixed in another release.
| @@ -16,12 +16,23 @@ a timestamp for a release is required. | |||
|
|
|||
| ## The Leaf Object | |||
|
|
|||
| - __UUID__ unique for this object | |||
| - __Uuid__ unique for this object | |||
There was a problem hiding this comment.
We've called this an identifier (which is of type UUID) in the OpenAPI Spec - we need to align in either direction.
Signed-off-by: Paul Horton <[email protected]>
Signed-off-by: Paul Horton <[email protected]>
Signed-off-by: Paul Horton <[email protected]>
Signed-off-by: Paul Horton <[email protected]>
Signed-off-by: Paul Horton <[email protected]>
Close #44