Clarify that a release publishes the latest draft, not a snapshot - #3370
Open
OcneanuVlad wants to merge 1 commit into
Open
Clarify that a release publishes the latest draft, not a snapshot#3370OcneanuVlad wants to merge 1 commit into
OcneanuVlad wants to merge 1 commit into
Conversation
A release action stores only a reference to an entry (content type, document ID, locale and action type), so publishing a release resolves each entry's current draft at publish time. Editing a draft after adding it to a release therefore changes what gets published, and a release cannot be pinned to a specific version. This was not documented anywhere on the Releases page, and is a common point of confusion for content managers using scheduled releases. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
👋 Thank you so much for contributing to the Strapi documentation! Our team is currently away and won't be able to review your pull request right away. Rest assured we'll get to it as soon as we're back. Thanks a lot for your patience! 🙏 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Adds a caution admonition to the Releases page clarifying what a release actually captures when an entry is added to it.
A release action stores only a reference to an entry (content type, document ID, locale, and action type), not a copy of its content. When the release is published, each entry's current draft is resolved at that moment. This means editing a draft after adding it to a release changes what gets published, and a release cannot be pinned to a specific version of an entry.
This behaviour was not documented anywhere on the Releases page. It is a recurring point of confusion for content managers using scheduled releases, where the gap between adding an entry and the release firing can be days.
Placed under "Including content in a release", right after the prerequisites block, so it covers both the single-entry and bulk-add flows and appears where the reader forms their mental model of what a release holds.
Supporting references in
strapi/strapi, pinned to commite64ce632af:release-action/schema.ts#L22-L46shows the release action schema has no content payload fieldrelease.ts#L31-L75reduces each action to{ documentId, locale }at publish timerepository.ts#L541-L621resolves the draft viapublishedAt: null, i.e. whatever the draft is at that instantThe closing sentence points at Content History as the way to publish an earlier version. Tiering lines up: Releases is Growth+ and Content History is Growth+/Enterprise, so anyone who can use Releases can use History.
Not labelled
flag: merge pending release, since this documents existing behaviour rather than an upcoming product change. Happy to add it if the Docs team disagrees.Related issue(s)/PR(s)
None. Prompted by a support question asking whether a scheduled release publishes the version of the draft from when it was added, or the latest one.