elastic / elastic/package-spec

[Change Proposal] Centralize conventions for "release badges"

Open
#286 1 comment 0 reactions 0 assignees View on GitHub
discuss
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.