## Summary This workstream establishes the Release Manifest as the Single Source of Truth for which modular component versions are compatible with each GitLab release. It decouples component release cadence from GitLab's monthly schedule, and provides the interfaces modular components use to publish their versions and consumers use to read them. ## Goals - Define a data model covering monthly, patch, and security releases - Provide interfaces for components to publish versions and for tools to read them - Keep modular component release cadence independent of GitLab's release schedule ## Deliverables | Deliverable | Expected outcome | Epic | Status | |---|---|---|---| | Data model | An agreed schema for component versions per GitLab release, published as a JSON Schema so writes validate automatically | &55 | :hourglass_flowing_sand: In progress | | Storage and access | A production home for both the mutable catalog and the immutable record, with writes limited to the release bot and reads open to consumers | &56 | :hourglass_flowing_sand: In progress | | Interface | Rake tasks in `release-tools` plus `common-ci-tasks` jobs, so components maintain their own entries and consumers can read them | &57 | :hourglass_flowing_sand: In progress | | Validation and rollout | Proof the write path works using `release-platform-canary`, then onboarding of readers and writers | &58 | Not started | | Monolith integration | auto_deploy resolves component versions from the manifest, retiring the `*_VERSION` files | &112 | :x: Likely not this Quarter | | Residual discussion | Consensus is reached on some implementation details that we decided to discuss after the initial implementation | &113 | :x: Definitely not this Quarter. ## Success Criteria - Schema is defined, documented, and machine validated - The manifest has a production home, with an immutable record for every published GitLab release - Modular components update their manifest entries automatically as part of their own release - Consumers read component versions from the manifest rather than tracking them by hand ## Related - Parent epic: &48 - Workstream 1: &37 - Workstream 2: &38 - Design document: [handbook!20713](https://gitlab.com/gitlab-com/content-sites/handbook/-/merge_requests/20713) ## DRI @jennykim-gitlab ## Participants The following team members are here to support this effort: - @siddharthkannan - APAC - @dat.tang.gitlab - EMEA - @jennykim-gitlab - AMER The following are points of contact to use when we reach target milestones: - AR Point of contact: \@jdrpereira - Caproni Point of contact: \@kkloss - Build Point of contact: \@rmarshall - Dedicated Point of contact: \@o-lluch ## Status <!-- STATUS NOTE START --> ## Status 2026-09-10 Validation work remaining: e2e write test, setting up artifact registry :clock1: **total hours spent this week by all contributors**: 40 :status: **TL;DR**: tooling and documentation for &55 and &57 are in review, and no real write has been observed end to end yet. :tada: **achievements**: - &56 completed - &57 - the trigger mechanism is settled (#22356) - the release manifest is opt-in in the release framework. It is off by default, and a component opts in with one flag in Terraform. - &113: new discussions have been recorded to address known gaps of the first iteration :issue-blocked: **blockers**: - N/A :arrow_forward: **next**: - Finalize documentation for first iteration - Verify the write path end to end with release-platform-canary (#22378) - Continue discussions for &113 and create followup issues _Copied from https://gitlab.com/groups/gitlab-com/gl-infra/software-delivery/-/epics/39#note_3812254714_ <!-- STATUS NOTE END -->