You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Automate and verify versioned documentation publication after minor releases #6762
After a minor release, docs.feast.dev should default to documentation for the latest stable Feast version. The release process should create the maintenance branch and verify that the corresponding GitBook space is published and selected as the default.
Current Behavior
Feast 0.65.0 was released on July 20, 2026, but docs.feast.dev still defaults to v0.64-branch. The repository has no v0.65-branch, and the GitBook collection has no v0.65 space. The current release.yml workflow publishes the release and updates stable, but the maintenance branch and GitBook steps remain manual post-release tasks.
This report is intentionally about the durable release-process gap rather than only publishing v0.65. A newer release may supersede v0.65 before the issue is addressed, but the same failure can recur for every minor release.
Inspect the upstream maintenance branches and GitBook version selector.
Specifications
Latest stable release: v0.65.0
Public documentation default: v0.64-branch
Missing maintenance branch: v0.65-branch
Subsystem: release automation and documentation publishing
Possible Solution
Extend the minor-release workflow to create the versioned maintenance branch automatically. Add a post-release check that confirms the matching GitBook space exists, is published, and is the default documentation version. If GitBook publication must remain manual, the workflow should fail or emit a clear actionable alert until those steps are complete.
The acceptance condition should be version-independent: the public documentation default matches the latest stable minor release after every release.
The release currently succeeds before the maintenance branch or GitBook version exists. I’ll add a post-release publisher that derives the version branch from the released tag, creates it only when absent, and refuses to move a conflicting branch.
The same helper will create or reuse the GitBook space, import the release branch, wait for sync, attach it to the public site, and switch the default only after the import succeeds. It will read the default back after publication and fail if the released version is not live. Reruns will verify and reuse matching resources.
The release workflow will call the helper only for a real release and provide GitHub/GitBook credentials plus GitBook organization and site IDs. The release-process documentation will describe those requirements and the recovery path.
Focused mocked tests will cover version parsing, first-time setup, safe reruns, conflicting branches, failed GitBook imports, and final default-space verification.
Implemented in #6763. The PR adds the post-release maintenance-branch and GitBook publisher, fail-closed verification, 10 focused tests, and release-process documentation. Live GitBook validation still needs a maintainer-owned test site and scoped token.
v0.66.0 gives us a concrete release-day reproduction. The release workflow completed successfully, and both stable and v0.66-branch point exactly at tag v0.66.0 (1d5be950cf). As of this comment, https://docs.feast.dev/ and /v0.66-branch/ return 404, while /master/ and /v0.64-branch/ return 200.
The Git branch step succeeded, but GitBook publication/default routing did not. The public default needs to be restored manually for v0.66. PR #6763 automates and verifies this step for future releases.
Activity
larrysingleton007 commentedon Aug 19, 2026
Implementation plan
The release currently succeeds before the maintenance branch or GitBook version exists. I’ll add a post-release publisher that derives the version branch from the released tag, creates it only when absent, and refuses to move a conflicting branch.
The same helper will create or reuse the GitBook space, import the release branch, wait for sync, attach it to the public site, and switch the default only after the import succeeds. It will read the default back after publication and fail if the released version is not live. Reruns will verify and reuse matching resources.
The release workflow will call the helper only for a real release and provide GitHub/GitBook credentials plus GitBook organization and site IDs. The release-process documentation will describe those requirements and the recovery path.
Focused mocked tests will cover version parsing, first-time setup, safe reruns, conflicting branches, failed GitBook imports, and final default-space verification.
fix: Automate versioned documentation publication
larrysingleton007 commentedon Aug 19, 2026
Implemented in #6763. The PR adds the post-release maintenance-branch and GitBook publisher, fail-closed verification, 10 focused tests, and release-process documentation. Live GitBook validation still needs a maintainer-owned test site and scoped token.
larrysingleton007 commentedon Aug 21, 2026
v0.66.0 gives us a concrete release-day reproduction. The release workflow completed successfully, and both
stableandv0.66-branchpoint exactly at tagv0.66.0(1d5be950cf). As of this comment,https://docs.feast.dev/and/v0.66-branch/return 404, while/master/and/v0.64-branch/return 200.The Git branch step succeeded, but GitBook publication/default routing did not. The public default needs to be restored manually for v0.66. PR #6763 automates and verifies this step for future releases.
fix: Automate versioned documentation publication (feast-dev#6763)
fix: Automate versioned documentation publication (feast-dev#6763)
chore(release): release 0.67.0
fix: Merge upstream feast-dev/feast master - resolve CSV conflict (#247)