diff --git a/docs/howto/use_package_storage_v2.md b/docs/howto/use_package_storage_v2.md
index e0ca28b552..b8f2fec79e 100644
--- a/docs/howto/use_package_storage_v2.md
+++ b/docs/howto/use_package_storage_v2.md
@@ -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: