Skip to content

Commit 64b8a71

Browse files
authored
HOWTO: Prerelease and stable version (#956)
* HOWTO: Prerelease and stable version * Address PR comments
1 parent 96ef368 commit 64b8a71

File tree

1 file changed

+14
-0
lines changed

1 file changed

+14
-0
lines changed

docs/howto/use_package_storage_v2.md

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,6 +16,20 @@ We recommend to use proper versioning instead and follow these rules:
1616
* a package with `version < 1.0.0` is a technical preview.
1717
* a package with `version >= 1.0.0` can contain prerelease tags (beta1, SNAPSHOT, next) on its version to indicate its prerelease state.
1818

19+
### Prerelease and stable version
20+
21+
A flat storage structure has implications for exposing revisions in the Fleet Integrations UI.
22+
23+
The Package Storage v1 allowed for pinning package revisions to particular stages and let package owners decide on when to promote the package.
24+
We received critical feedback about this approach as it required package owners to take a manual action to promote package revisions.
25+
The Package Storage v2 assumes that every published revision is exposed to Fleet users, and package owners can release their packages
26+
as snapshots or technical previews using semantic versioning (prerelease tags).
27+
28+
Notice: if you prefer Fleet users not to pick up and install prereleases, it's recommended to be cautious with exposing new features
29+
until [kibana#122973](https://github.com/elastic/kibana/issues/122973) is implemented. With this feature, users can decide
30+
whether they can pick up prerelease package revisions. If you can't expose new features for any reason, you should stick
31+
to a local development environment instead.
32+
1933
## What is the goal of storage migration from v1 to v2?
2034

2135
We identified a few issues in v1 design, we couldn't easily overcome or patch:

0 commit comments

Comments
 (0)