elastic / elastic/package-spec
[Change Proposal] Centralize conventions for "release badges"
- Dominant language
- Go
- Stars
- 20
- Forks
- 93
- Avg merge
- 15h 10m
- Merged PRs (30d)
- 12
Description
After https://github.com/elastic/package-spec/issues/225, the stability level of a package is decided by semantic versioning. Semantic versioning by itself only establishes that a package is stable if its version is not 0.x and it doesn't contain prerelease labels. If more prerelease levels are needed, conventions need to be defined.
As part of https://github.com/elastic/kibana/issues/122973, we defined some conventions for the "release badges" that should be displayed to users based on semantic versioning:
* `0.x` versions -> "Technical Preview"
* `x.x.x-beta...` -> "Beta"
* `x.x.x-rc...` -> "Release Candidate"
* `x.x.x-preview...` -> "Technical Preview"
* Other prerelease labels won't be allowed in the spec, but if they appear, default to "Beta".
We have found that this convention is needed in several user-facing places, at least in the following ones:
* `elastic-package status`.
* Kibana/Fleet.
* Documentation site https://docs.elastic.co/en/integrations.
As this is not expected to change frequently, an option can be to have this mapping implemented on each place where it is needed, but this can lead to incoherences, so it'd be nice to have this in a central place.
The natural place to have this kind of conventions would be in the spec, but this cannot be easily consumed by other tools.
Another place, as proposed in https://github.com/elastic/kibana/issues/122973#issuecomment-1049923129, can be the package-registry, that in principle all the other services use for packages obtained from there.
Contributor guide
Assessment
This issue has not been assessed yet.