Skip to content

HOWTO: Prerelease and stable version #956

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 6, 2022
Merged

HOWTO: Prerelease and stable version #956

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2941c34
HOWTO: Prerelease and stable version
Sep 5, 2022
edf9e99
Address PR comments
Sep 5, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions docs/howto/use_package_storage_v2.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,20 @@ We recommend to use proper versioning instead and follow these rules:
* a package with `version < 1.0.0` is a technical preview.
* a package with `version >= 1.0.0` can contain prerelease tags (beta1, SNAPSHOT, next) on its version to indicate its prerelease state.

### Prerelease and stable version

A flat storage structure has implications for exposing revisions in the Fleet Integrations UI.

The Package Storage v1 allowed for pinning package revisions to particular stages and let package owners decide on when to promote the package.
We received critical feedback about this approach as it required package owners to take a manual action to promote package revisions.
The Package Storage v2 assumes that every published revision is exposed to Fleet users, and package owners can release their packages
as snapshots or technical previews using semantic versioning (prerelease tags).

Notice: if you prefer Fleet users not to pick up and install prereleases, it's recommended to be cautious with exposing new features
until [kibana#122973](https://github.com/elastic/kibana/issues/122973) is implemented. With this feature, users can decide
whether they can pick up prerelease package revisions. If you can't expose new features for any reason, you should stick
to a local development environment instead.

## What is the goal of storage migration from v1 to v2?

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