There is currently a partial overlap in different features regarding the stability level of a package, that uses to bring confusion to integration developers and users:

• release label in manifests can be experimental/beta/ga.
• Semantic versioning, a package with a version >= 1.0.0 is (could be) considered "stable".
• There are three registries: snapshot/staging/production.

Apart of the overlap, there is no enforcement between these features, so it can be possible to find in the production repository a 1.0.0 package marked as experimental.

The proposal would be:

• Remove the release labels from the main manifest. To avoid breaking changes they could be marked as optional in the spec, and eventually be ignored everywhere, package registry API could do best-effort interpretation for old experimental-related queries.
• Pre-releases semver fields can be defined to release unstable versions. Packages stability (and supportability) would be determined only by their version, not from its origin. This implies the need of a change in a package to release it as stable, but this is ok, as this allow to introduce an approval step in the process.
• "Unstable" or experimental features could be still added to GA packages, but must be disabled by default. An experimental feature, causing an issue to a user of a GA package not interested in this feature should be considered a bug in the package. Release tag can still be used at the datastream level to mark datastreams or integration tiles as beta or experimental.
• Users can configure the source of packages, a single source can be configured now, but this may change in the future, the source doesn't determine the stability of a package.
• Users can optionally enable the use of pre-releases to use non-GA packages. Limited or no support level would be granted for these packages.
• Eventually snapshot and staging registries may be removed (Removal of the package registry and storage stages package-storage#3666).

Some examples with this model:

• Package foo 0.5.0 wouldn't be considered stable, wherever it is published.
• Package bar 2.0.0 would be considered stable, and should be supported by their maintainers/owners.
• Package bar 2.1.0-beta wouldn't be considered stable, but a release candidate.

Discarded ideas:

• The registry that serves the package is relevant to its stability. In principle we are going to continue using the promotion model, and it can be safely assumed that the production registry contains more stable packages than the other ones. But consumers of packages (as Kibana/Fleet) shouldn't need to interpret the stability of packages from its origin (comment).
• Rejection of "unstable" packages in the production repository should be enforced (consequence of previous comment).
• Removal of the release tag at the datastream level delayed as it belongs to a broader discussion about how to tag experimental/beta features in GA packages.

Required changes

• Integrations: review consistency in the use of semver and the release tag.
  • security_detection_engine mislabeled in 7.x Some GA packages no longer appear in /search without experimental/pre-release flag package-registry#793.
  • apm always uses release: ga, even for non-ga versions Remove release tag from APM package apm-server#7792.
• package-spec: Deprecate release, extend documentation of version to describe the use of pre-release semver fields.
  • Deprecate the release tag #256
• elastic-package: Review uses of the release flag and update documentation.
  • Ignore deprecated release tag from manifests elastic-package#647
  • Deprecate release label integrations#2651
• package-registry: Add support for a /search argument that lists packages with pre-release semver fields, disable it by default or depending on a flag, and try to keep compatibility with current API arguments related to versioning (experimental...).
  • Add prerelease search parameter and deprecate experimental package-registry#785
• package-storage/distribution: If a flag is added to control this behaviour, decide the default option for each registry. Not needed, currently kibana always use experimental=true.
• fleet: Add a configuration toggle to enable the search installation of pre-release packages.
  • [Fleet] Add option to toggle search of prerelease packages kibana#122973
• external documentation: Review how these changes affect external integrations documentation.