[Change Proposal] Remove release tag from packages

[jsoriano]

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.

[ruflin]

Overall I like the direction this is going. Few points from my end:

• Prerelease in a separate registry: This might work well for our internal workflow for testing. But at one stage, I expect also the community to be able to build packages and publish them. Some of these packages will be pre GA at first. A user should not have to think about pushing to different registries based on the release state. So we should make it possible to have pre-release packages also "production" registry.
• Select stability of packages: Initially Fleet only showed the GA packages and beta/experimental had to be enabled. But we changed it as too many packages were still beta. It is likely time to change this back and users can select if they want to see beta or experimental in Fleet.
• Filtering: You mention to remove the release label from the manifest. I would assume the index still creates a release field or similar to make sure the filtering on the release state is efficient. beta and experimental comes from how we defined the release state of other products at Elastic. I assume removing it will mean we have only pre-release left?

One thing that came to mind reading the above: What if we have only a single registry for everything? One of the changes needed would be that it would be acceptable to remove pre release packages.

[jsoriano]

Overall I like the direction this is going. Few points from my end:

• Prerelease in a separate registry: This might work well for our internal workflow for testing. But at one stage, I expect also the community to be able to build packages and publish them. Some of these packages will be pre GA at first. A user should not have to think about pushing to different registries based on the release state. So we should make it possible to have pre-release packages also "production" registry.

Yes, I am also thinking on the community, and for that I also think that it would be better to simplify this in some direction 🙂 Maybe we can leave open to the owner of the integration how to use versioning and the different registries, but I would like to remove one of the three things.

For pre-release packages I see two possible approaches:

• Completely new packages have a < 1.0 version.
• Released packages with >= 1.0 can have a "beta channel", that in our case would be to publish them in the staging registry. When the developer is confident with the package, they promote to production the package as is, no need to relabel it or anything else.

• Select stability of packages: Initially Fleet only showed the GA packages and beta/experimental had to be enabled. But we changed it as too many packages were still beta. It is likely time to change this back and users can select if they want to see beta or experimental in Fleet.

+1, we should consider offering only stable packages by default.

• Filtering: You mention to remove the release label from the manifest. I would assume the index still creates a release field or similar to make sure the filtering on the release state is efficient. beta and experimental comes from how we defined the release state of other products at Elastic. I assume removing it will mean we have only pre-release left?

Filtering in general would be actually easier, because it would be less needed: users have configured by default only the production registry, and packages there should be stable enough.
If this proposal is accepted, the release label will be ignored in the registry APIs.

The open question here is to decide if we allow < 1.0 packages in the production registry, if we don't, then all the packages in the production registry are going to be stable. If we do, we should show something in the UI, but still no filtering would be needed.

One thing that came to mind reading the above: What if we have only a single registry for everything? One of the changes needed would be that it would be acceptable to remove pre release packages.

This would be another valid proposal, it would also remove one of the three things I mention, so we would only have:

• release label in manifests can be experimental/beta/ga.
• Semantic versioning, a package with a version >= 1.0.0 is (could be) considered "stable".

But I still see some overlap there (should we check that no package is published as experimental with a >= 1.0 version?). And it would be more difficult to have something like a "beta channel", it would imply to retag the package as beta, and then when the release is approved, do another change and another release with the tag set back to ga.

There is a third option, that is to remove both things, the multiple registries, and the release labels, and rely on semantic versioning only: 0.1.0 is not GA, 1.5.5 is GA, 1.6.0beta1 is not GA. But then we have to keep some filtering for unstable versions, and additional releases are needed (instead of just promotions) when a release is approved.

[ruflin]

Lets focus for a moment on one vs multiple registries. There is the registry we run and there are going to be the registries that are run by users. Likely the registries run by users could also have additional packages inside at one point. These could be prerelease or GA. Requiring multiple registries for prerelease packages seems to put some limitations in that are not necessarily required. My take take is we should allow prerelease packages in the production registry.

In Fleet today we allow a single registry. You can point it to the production, testing, your own but not multiple registries. This keeps things simple for Fleet. One source of truth, no conflicting packages, only one remote request for search etc. If possible, it is a model I would like to keep for simplicity reasons. But assuming at some point we would allow pointing users to multiple registries, it would be likely n registries. And it would not only be for beta vs GA but different packages. And each of these registries could contain beta packages. Here again, we are back to each registry itself should support prerelease packages.

One of the reasons for the snapshot registry we have today was also to new registry releases out in the wild to make sure we don't break anything. But the value of this has decreased over time as the package-registry has become more stable and the test suite increased.

I'm more and more leaning in the direction there should be likely a single registry and prereleases also go into it. This has at least 2 requirements:

• Unreleased packages can be cleaned up. For this to work, Kibana must cache these packages locally to make sure things don't break
• Dockerfile does not contain the packages directly as otherwise it will keep growing.

[jsoriano]

I would prefer to go in the direction of removing the release tag because I think it would remove more complexity, and it could also cover some of the use cases you mention. But having a single registry would also serve as a simplification of this.

Still, I think that some things would still be a bit complicated, specially for package developers, and a bit counter-intuitive for users. for example, how would be steps to make a prerelease of a GA package to make a prerelease:

• Package exists as 2.5.0, I want to release new changes, with a prerelease version.
• I add new features, set the release tag to beta, and publish it in the production registry as 2.5.1.
• I validate the changes, I set the release tag to ga back, and I need to publish another version, 2.5.2 (with an empty changelog?).

With multiple repositories:

• Package exists as 2.5.0, I want to release new changes, with a prerelease version.
• I add new features and publish it in the staging registry as 2.5.1.
• I validate the changes, and I promote the 2.5.1 package to the production repository.

(Still, having "not validated" versions would create additional versions not seen by users).

Also, take into account that the snapshot/staging/production registries being now different registries is almost an implementation detail, they could be different "stages" in a single registry.

[jsoriano]

@ruflin and I had a discussion offline about this (Nicolas, feel free to edit the comment 🙂), we had common agreement on some points:

• To remove the beta/experimental release tags.
• To double down on semver, ensuring that prerelease fields (1.0.0-rc, 1.0.0-rc.1, 1.0.0-beta.1...) are supported in the ecosystem tooling and in Kibana/Fleet (we already have -next, so it may be already supported). Still maintainers may decide to do continuous deployment on every change.
• If these changes are done, make a best effort to maintain current API (e.g. by interpreting that a package with a version < 1.0 is beta/experimental, even if it doesn't have a release tag).
• Eventually, when all this is in place, we may discuss about removing or not the different registries, and the promotion steps.

Not directly related, we also discussed about the relationship between the different registries and the maturity of packages. Currently snapshot/staging is used both to test new versions of packages, and to test new versions of the registry. We discussed that:

• Staging of packages and the registry should be decoupled, in general the latest stable registry should be used in all public-facing registries. Other deployment models as canaries or blue-green deployment could be used for staging of the registry.
• Package registry could be migrated to a more continuous deployment model.

[jsoriano]

Updated description after the latest comments.

[simitt]

Adding some use case regarding the topic of one vs. multiple registries:
We have a couple of packages that follow stack versioning (for example apm). During the dev process, we need to be able to publish a pre-release package for the upcoming release multiple times. Otherwise any features depending on the changes would only be testable with local registries during the dev cycle, which is not practical for automated tests and for cross-team collaboration.
So far we are overwriting the package with the same version on snapshot/staging registries, but we absolutely avoid doing this on production, and only release the production package close to the stack release date. If we end up having only one registry at some point, we would probably need to publish with pre-release versions in production (for example: 8.2.2-rc3). In this case we need to be absolutely certain that such pre-release packages are never used in users production environments.

[mtojek]

The issue I linked above shows some use cases for the release tag and presentation in docs. Let's keep in mind too.

[mtojek]

@simitt

So far we are overwriting the package with the same version on snapshot/staging registries, but we absolutely avoid doing this on production, and only release the production package close to the stack release date. I

This is an anti-pattern and you shouldn't follow this path at all. The endpoint team creates new revisions with release tags, for example: 1.2.3-dev1, 1.2.3-dev2, 1.2.3-dev3, 1.2.3. Revisions marked with "devX" are subjected to QA tests.

BTW we are actively working on signing package revisions and forbidding direct pushes to the Package Storage, so you will need to address these problems in the future.

[jsoriano]

In this case we need to be absolutely certain that such pre-release packages are never used in users production environments.

Regarding this, this would be covered by the current proposal, even with a single registry. A package that follows stack versioning, for example for 8.2.2, could be released as 8.2.2-rc1 with the constraint kibana.version: 8.2.2. With this constraint, during the development/FF phases this package would be available only for snapshots of Kibana 8.2.2, but not for any previous released version. Once Kibana 8.2.2 is released, there should be a released 8.2.2 package of APM too.

[mtojek]

@jsoriano I navigated to this PR from the Package Storage v2 doc.

I'd like to double-check one thing: It won't be possible anymore to consider an existing package a "stable" one, right?

Currently:

I'm working on nginx-1.8.0. I pushed it to the Integrations, promoted it to the staging. I did some testing, it looks fine, let's promote it to production.

With the proposal:

I'm working on the nginx-1.8.0-prerelease. Pushed it to the Integrations, promoted it to the staging. I did some testing, it looks fine. To release it as "nginx-1.8.0", I need to create another PR to Integrations and promote it through stages again. Right?

I'm not sure if it's an improvement in terms of developer experience as the package owner has to publish the package twice. I think this will be useful if we also decide to deprecate stages as we talk in the package storage v2 doc.

[jsoriano]

It won't be possible anymore to consider an existing package a "stable" one, right?

With the proposal a package is stable following the semver premises: if its version is >= 1.0.0, and it doesn't include prerelease labels. It doesn't depend on where it is published.

To release it as "nginx-1.8.0", I need to create another PR to Integrations and promote it through stages again. Right?

Yes, this is one of the parts that made me reluctant of removing the staging repository on a first phase, I see the value of multiple registries or delivery channels for this use case, I talk a bit about this in #225 (comment).

I'm not sure if it's an improvement in terms of developer experience as the package owner has to publish the package twice. I think this will be useful if we also decide to deprecate stages as we talk in the package storage v2 doc.

The improvement would be in removing different options to do similar things. Another improvement is to get rid of the promoting step, that has proven to be confusing for developers, we would only publish packages.
We can go step by step. First removing the release tag, and then later considering if we should also get rid of the multiple registries. My feeling is that we shouldn't need the multiple registries.

Perhaps we have to think about the act of publishing. Merging a change and having a build of the package that can be internally used by the developer team doesn't imply that this package should be made available to the public in any form.

For example, for the case of the nginx package you mention, if the only reason of publishing the prerelease is to do some internal validation, then maybe the package shouldn't have been published to any public registry.
If there are other reasons to release the beta/rc packages, as having broader testing or feedback from the community, then I think that it can make sense to make the additional commit to explicitly approve and declare the final release, and then publish it.
It is also possible that in the last rc package some last-minute minor issue was found but it isn't worth to release another rc, then this change would be included only in the final version. This happens in software following this schema, for example Beats 7.0.0 has changes that weren't included in the last public rc (7.0.0-rc2).

Each developer team might decide about using or not prerelease labels and for what packages and versions.

[ruflin]

On my end, I try to stop thinking about a PR as the release mechanism but more an API that a few minutes later I can check, if the release was successful or not. As soon as "publish" is done on a package, it will be released a few minutes later assuming all checks passed.

[jsoriano]

After some internal discussions we have decided to keep the release tag at the datastream level, so it can be still used to individually tag datastreams or integration tiles as beta or experimental. Updated description accordingly.

[jsoriano]

@joshdover thanks for your detailed explanation and the proposals. Please take into account that this situation can already happen now without any change. A developer may release a prerelease version according to semver, and forget to change the release tag from ga to beta. This package would appear as stable in current versions of kibana and users could upgrade to it. One of the main motivations for this proposal is to avoid this kind of incoherences.

We could right now remove the release tag from all packages. It is optional and deprecated now, and current package registry API "emulates" it according to the new definition, for current versions of Kibana. This would reduce the chance of finding the situation you describe. A foo@1.3.0-dev1 package without a release tag wouldn't be exposed as GA by the registry, to any version of Kibana.

We can also consider adding an additional validation in the package spec, so it is not possible to have non-ga packages according to semver with release: ga, but this could break some of the existing packages that are in corner cases (like this one, with release: ga but prerelease according to semver). We had an internal thread about these packages, and some of them are going to continue with this incoherence.

I think we agree that anything we do regarding this, should target addressing the incoherences between semver and the release tag.

Regarding your proposals:

• Require that any packages with a prerelease version that are published to production EPR have a minimum constraints.kibana.version that matches whichever Kibana version we end up shipping [Fleet] Add option to toggle search of prerelease packages kibana#122973

I wouldn't like to enforce any kibana version for this, this would discourage the support of broader ranges of versions, something we want to encourage.

• Default search request would only return packages with stable semver version

This is the approach proposed here, and already implemented in the registry.

• experimental=true would return packages with release: "beta" or release: "experimental" with stable semver versions (still excludes packages with prerelease suffix)

Then packages with prerelease suffixes wouldn't appear on current versions of Kibana, right? I think they should still appear, if not, package developers would need to release different sets of prereleases for the different implementations of Kibana.

In any case I think that the ideal place to place any compatibility logic is here, when experimental=true is used, as we are deprecating this parameter and the only purpose to keep it is to keep compatibility with current clients.

• prerelease=beta would ignore the release tag and return packages with -betaX prereleases suffix. Similar for prerelease=dev, prerelease=rc, prerelease=all, etc.

prerelease already ignores the release tags (unless experimental is also used), but doesn't do any filtering on the prerelease label used. This would be a different feature, right? How would it help here?

[joshdover]

Please take into account that this situation can already happen now without any change. A developer may release a prerelease version according to semver, and forget to change the release tag from ga to beta. This package would appear as stable in current versions of kibana and users could upgrade to it. One of the main motivations for this proposal is to avoid this kind of incoherences.

Yes, it could happen today but is unlikely due to the fact that we have snapshot and staging registries. Whenever we deprecate/remove those, this situation becomes the norm: all prerelease packages (including dev) will be shown to users on older Kibana versions.

• Require that any packages with a prerelease version that are published to production EPR have a minimum constraints.kibana.version that matches whichever Kibana version we end up shipping [Fleet] Add option to toggle search of prerelease packages kibana#122973

I wouldn't like to enforce any kibana version for this, this would discourage the support of broader ranges of versions, something we want to encourage.

To be clear, the versions I'm most worried about are the 7.17.x releases, a version that many customers will use until the EOL date (18+ months from now). I'm less worried about this for users on 8.x releases since they can easily upgrade and likely will, meaning there should be less users on the 8.x train that should receive prerelease packages (because we'll change Kibana's search request in an early 8.x release).

• experimental=true would return packages with release: "beta" or release: "experimental" with stable semver versions (still excludes packages with prerelease suffix)
  Then packages with prerelease suffixes wouldn't appear on current versions of Kibana, right? I think they should still appear, if not, package developers would need to release different sets of prereleases for the different implementations of Kibana.

Yes that's a good point, let's drop this idea for now.

prerelease already ignores the release tags (unless experimental is also used), but doesn't do any filtering on the prerelease label used. This would be a different feature, right? How would it help here?

Apologies, I missed that this new flag was already added, had to look at the specific PRs to realize this.

Problem

I'd like to focus on and agree on the problem before jumping to solutions too quickly. Here's how I see it:

• Today, users get all prerelease versions published to the production EPR.
• In the future, the production registry will not only host 'tech preview' and 'beta' packages, but also 'dev' packages. Though technically these are also prerelease versions and technically this is possible before this change, in practice users do not get dev packages today so this would be new behavior.
• Integration developers and users alike probably do not expect dev packages to be released to users.
• We should prevent dev packages from being shipped to users of a GA product (Fleet is GA)
• However, integration developers still need a way to test dev packages on older Kibana versions before they're released to users.

Solution

• Require that any packages with a prerelease version that are published to production EPR have a minimum constraints.kibana.version that matches whichever Kibana version we end up shipping [Fleet] Add option to toggle search of prerelease packages kibana#122973 in. This would ensure that users on older Kibanas never see prerelease versions of packages that are stable.

I think we may be able to use some version of this idea to solve this problem, if we do indeed agree it's worth solving. However, it wouldn't be without some drawbacks. Here's what I'm thinking:

1. Require a minimum constraints.kibana.version of ^8.3.0 (for example) on any package published to the production registry with a prerelease semver version
2. Integration developers can use the xpack.fleet.developer.disableRegistryVersionCheck Kibana config flag to test this package on 7.17.x
3. When publishing the stable version, developers can reduce the constraints.kibana.version to ^7.17.0
4. Do not change the behavior of experimental=true

The main drawback here is step (3) since this would need to be something developers remember to do. Alternatively, we could make this behavior automatic. Maybe something like this would work:

1. No changes to constraints.kibana.version validation / requirements
2. Update experimental=true with this behavior:
   • If no kibana.version supplied on the request, use the current behavior (return all prerelease semver packages, ignoring the release tag)
   • If kibana.version is supplied on the request, filter out all prerelease semver packages except -betaX
3. Developers can then use xpack.fleet.developer.disableRegistryVersionCheck Kibana config flag to test this package on 7.17.x while no end users on older Kibanas will get dev packages from the production registry.

[jsoriano]

@joshdover I think that you are bringing many good points, and this is by itself a complex discussion, many cases to contemplate 🙂 It may be easier to see if we split the different problems, it looks to me that we are mixing different things here.

This proposal is mostly about the deprecation of the release tag and the increased use of semantic versioning as a well-known schema. Not so much about the removal of the snapshot and staging registries. If you agree with the advantages of relying only of semver instead of having both semver and the release tags, I think that we could open a different discussion about the possible removal of the registry stages.

The removal of the registry stages is mentioned in this proposal because relying on semver has some related consequences mentioned in the description above:

• Packages stability (and supportability) would be determined only by their version, not from its origin. (a prerelease package in the production registry shouldn't be considered GA, a GA package in the staging registry should/could be considered GA).
• As a consequence of the previous point, Eventually snapshot and staging registries may be removed. But this is not a requirement for the proposed change here.

The removal of the registry stages is being taken more into consideration in the Package Storage v2 efforts. There we are focusing on having a single public registry (as there is a single docker hub, or a single npm). Worst case, alternatives could be considered, as duplicating the registry, or keeping current deployments till the sunset of 7.17. But this is separated to the use of semantic versioning.

If we remove the removal of the staging/snapshot registries from the equation, there are still the questions about tech preview/beta vs dev packages. In my opinion we shouldn't do any special handling between them. Main reasons:

• We want to keep this as simple as possible, reducing the chances of having conventions that could confuse users and developers (as the confusions we had with the release tag and 1.0 versions). And reducing the logic we need to implement everywhere to support this.
• We want to give developers the freedom to define their release cycles. There can be developers that don't publicly publish any prerelease version, there can be teams that publish development versions for earlier feedback from real users. There can be teams with their own internal registries, while others use only the public one. We want to have a simple model, that suites different teams. Developers should be able to decide their development workflows. Users should be able to decide if they want only GA versions or not.
• We probably need to make a better job differentiating the build of a package from its public release. There can be internal builds of packages that are never published to the public registry.

Regarding your proposals, first one looks complicated and a bit error prone for developers as you mention. This would also discourage developers of maintaining their packages for broader versions of the stack, something we want to encourage.
If we do anything on this regard, I would prefer something like the second option, because it only affects the behaviour when experimental=true is used.

I will open an issue to discuss possible improvements in the registry to support old versions, and a github discussion to discuss about the removal of the staging and snapshot registries.

2. Integration developers can use the xpack.fleet.developer.disableRegistryVersionCheck Kibana config flag to test this package on 7.17.x

3. Developers can then use xpack.fleet.developer.disableRegistryVersionCheck Kibana config flag to test this package on 7.17.x while no end users on older Kibanas will get dev packages from the production registry.

One comment about these points. At some point package developers shouldn't even need a registry to test their packages, they should be able to build it (elastic/elastic-package#550), and install it directly in Kibana (elastic/kibana#70582).

[jsoriano]

Discussion to discuss about the removal of the staging and snapshot registries: elastic/package-storage#3666

[juliaElastic]

@jsoriano I have a question on deprecating release tag. Are packages going to publish release tag at all going forward? And if so, for how long?
I'm asking because of backward compatibility.
Currently, kibana shows the badge on Integrations UI based on the release tag value (beta/experimental). Let's say that kibana changes the logic to show the badge based on semver instead in 8.x.
However, older versions of kibana are still relying on release tag, so it would mean all packages would look like ga on the UI (no badge)

[jsoriano]

Are packages going to publish release tag at all going forward? And if so, for how long?

The release tag is already marked as deprecated, and optional. Packages can already be shipped without this tag.

For backwards compatibility with new packages without a release tag, the package registry fills the gap following semantic versioning, here:
https://github.com/elastic/package-registry/blob/2265fb37a31aad1bbc7201f10af683d46ec8f5f8/packages/package.go#L280-L282

So at the API level, packages without a release label are going to continue behaving as if they had one. They will have release: beta if they are prereleases according to semver, and release: ga otherwise.
When I say at the API level I mean that the content of the package is not changed, that means that it won't contain a release label in the manifest. From the tests I did with current versions of kibana, this didn't look like a problem, it seems that release is only read from calls to the APIs and not from the manifest (but I may be wrong).

We don't plan to remove this compatibility logic anytime soon, this will likely stay there while there are versions of Kibana using it (we can assume forever).

We also expect that nothing new is built relying on the release label, as it is deprecated.

[juliaElastic]

@jsoriano
thanks, it makes sense, I'll double check the kibana logic, as you said it might not be a problem then

[jsoriano]

Thanks @juliaElastic, please let me know if you find a case where not having the release tag in the manifest can be a problem.

[joshdover]

Apologize for the delay, thanks for taking the time to answer these questions, @jsoriano.

This proposal is mostly about the deprecation of the release tag and the increased use of
semantic versioning as a well-known schema.

Great point. Let's focus on just this change for the registry in general. Thank you for clarifying they are being considered separately.

there are still the questions about tech preview/beta vs dev packages. In my opinion we shouldn't
do any special handling between them.

A few questions:

• Should we implement the mapping logic in [Fleet] Evaluate impact of moving to package semver instead of release tag in labeling kibana#126348 (comment) in the registry so it can be consistent across Kibana and the Integration docs pages?
• Similar to above, should we have share logic for showing beta, but not dev packages to users across Kibana and the integration docs?
• Though we're not removing the staging or snapshot registries in this change, should we have a policy that dev and tech preview packages should not be deployed to production for the time being to avoid the issue of distributing these packages to users of older stack versions?

We probably need to make a better job differentiating the build of a package from its public release. There can be internal builds of packages that are never published to the public registry.

+1 it would be helpful to have a build number or git sha in addition to a semantic version number, like we do for stack builds

[juliaElastic]

Should we implement the mapping logic in elastic/kibana#126348 (comment) in the registry so it can be consistent across Kibana and the Integration docs pages?

@joshdover I asked the same question here: elastic/kibana#122973 (comment)

[jsoriano]

• Similar to above, should we have share logic for showing beta, but not dev packages to users across Kibana and the integration docs?

I partially answer this also in elastic/kibana#122973 (comment). Functionally there shouldn't be any difference between any public non-GA versions. The labels will give users information about what to expect in these cases.

I think it should be easy to keep a cluster with GA packages only, as well as discovering any kind of packages, but installing non-GA versions should require some extra action or acknowledgement, specially for users currently using GA versions of the package. Beta shouldn't be an exception here.
Handling beta versions as a special case for non-GA versions can be dangerous, there could be cases where users unintentionally end up using beta (non-GA) versions, and there can be cases where developers unintentionally release beta versions with wrong expectations on the users that may end up using their package. I think it is more clear if users and developers clearly know what is GA and what it isn't, without grey areas in between. It is easier to understand and less error-prone to implement.

• Though we're not removing the staging or snapshot registries in this change, should we have a policy that dev and tech preview packages should not be deployed to production for the time being to avoid the issue of distributing these packages to users of older stack versions?

I don't think we have a policy like this one at the moment and anyone could publish now an experimental package and it would be available for everyone. Has this caused any issue so far?

We may be afraid of this being more an issue with the long support of 7.17, but other factors make me think that this may not be such a probable issue: Users staying in 7.x are probably not going to do unattended upgrades, or install new packages. New packages are the main candidates to have more unstable technical previews, and developers creating these packages are probably going to target 8.x only.

[joshdover]

I don't think we have a policy like this one at the moment and anyone could publish now an experimental package and it would be available for everyone. Has this caused any issue so far?

We may be afraid of this being more an issue with the long support of 7.17, but other factors make me think that this may not be such a probable issue: Users staying in 7.x are probably not going to do unattended upgrades, or install new packages. New packages are the main candidates to have more unstable technical previews, and developers creating these packages are probably going to target 8.x only.

It has not become an issue so far. Do keep in mind that some internal packages do automatically run package upgrades on Kibana startup as of 7.16.0 (apm, endpoint, synthetics, fleet_server, elastic_agent). Of these, fleet_server and elastic_agent are still using a version constraint that would ship to both 7.16 and 8.0 and endpoint uses a constraint that would ship to 8.0. apm and synthetics seem to bumping their version constraint on each stack release, so those should not be problems.

[jsoriano]

Closing this, in principle the only pending change is in Fleet, that is being discussed in elastic/kibana#122973.