Update Release Timeline and Release Management Page

[ther3sa]

Pull request overview

This PR updates the website’s Release Timelines and Release Management documentation to reflect the current Catena-X ecosystem release cadence, naming, and detailed phase/milestone descriptions, including expanded explanations for Catena-X vs Eclipse Tractus-X responsibilities.

Changes:

• Refines the Timelines page content with updated release names (Neptune/Proteus/Sirius/Procyon), adds detailed phase & milestone tables, and expands explanations of the release cadence/process.
• Reworks the Release Management page to better explain governance vs technical implementation layers, ecosystem release composition, lifecycle states, and versioning concepts.
• Updates internal cross-references between Release Management and Timelines.

Reviewed changes

Copilot reviewed 2 out of 7 changed files in this pull request and generated 5 comments.

File	Description
src/pages/timelines.md	Updates the release timeline narrative, adds detailed milestone tables, and restructures the release-management phase documentation within the timelines page.
src/pages/release-management.md	Rewrites the release management overview (governance/implementation, lifecycle, versioning) and adds/updates reference links to the timelines and operating model.

[Copilot]

Pull request overview

This PR updates the website’s Release Timelines and Release Management documentation to reflect the current Catena-X ecosystem release cadence, naming, and detailed phase/milestone descriptions, including expanded explanations for Catena-X vs Eclipse Tractus-X responsibilities.

Changes:

• Refines the Timelines page content with updated release names (Neptune/Proteus/Sirius/Procyon), adds detailed phase & milestone tables, and expands explanations of the release cadence/process.
• Reworks the Release Management page to better explain governance vs technical implementation layers, ecosystem release composition, lifecycle states, and versioning concepts.
• Updates internal cross-references between Release Management and Timelines.

Reviewed changes

Copilot reviewed 2 out of 7 changed files in this pull request and generated 5 comments.

File	Description
src/pages/timelines.md	Updates the release timeline narrative, adds detailed milestone tables, and restructures the release-management phase documentation within the timelines page.
src/pages/release-management.md	Rewrites the release management overview (governance/implementation, lifecycle, versioning) and adds/updates reference links to the timelines and operating model.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

🌿 Branch Deployment

Your changes have been deployed to the branch environment:

🌐 Branch URL: https://catenax-ev.github.io/branch/feat-release-timeline-2027/

This comment is updated automatically on every push to this branch.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 7 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (3)

src/pages/timelines.md:10

• This states that each ecosystem release consists of two release cycles, but later the page explicitly documents an exception (26.12 skipped; Proteus has only one release part). Consider softening this to avoid an internal contradiction.

The following overview provides a high-level roadmap of the planned Catena-X ecosystem releases. Each ecosystem release consists of two release cycles.

src/pages/release-management.md:23

• This relative link targets the source file (./timelines.md). On the built site, pages are routed without the .md extension, so this may resolve incorrectly. Link to the page route instead (consistent with /release-management used elsewhere).

An overview of upcoming ecosystem releases is available in the [**Timelines**](/timelines).

src/pages/release-management.md:59

• The table says "Artefact Versioning" uses calendar versioning, but the "Versioning" section below (and the Operating Model) states artefacts use SemVer while releases use CalVer. Suggest renaming this row to make it clear it refers to Catena-X/Tractus-X release versioning, not artefact versioning.

| Catena-X & Eclipse Tractus-X Release Versioning | Calendar Versioning (e.g. 27.09) |

[stephanbcbauer]

Total cool

[stephanbcbauer]

LGTM

[Copilot]

Pull request overview

Copilot reviewed 2 out of 7 changed files in this pull request and generated 5 comments.

Comments suppressed due to low confidence (2)

src/pages/timelines.md:4

• Grammar: "Catena-X ecosystem release" should be plural (this page lists multiple releases).

Here you can always find the **most up-to-date release schedules** for **Catena-X ecosystem releases**.

src/pages/timelines.md:348

• The admonition closing marker has trailing spaces. Docusaurus admonitions are safest when the closing delimiter is exactly ::: on its own line (without extra spaces), otherwise parsing can become fragile.

:::  

[Copilot]

Pull request overview

Copilot reviewed 2 out of 7 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (2)

src/pages/timelines.md:303

• The closing delimiter for this Docusaurus admonition includes trailing spaces (::: ). Docusaurus expects a line containing only :::; the trailing spaces can prevent the admonition from closing and cause the rest of the page to render inside the info box.

:::info

After the Internal Planning Day, **no new standards may be added** to the release. From this point on, only feedback on already-presented standards can be incorporated. Standards that were not presented during the Internal Planning Day will **not be part of the release**.

:::  

src/pages/timelines.md:348

• The closing delimiter for this :::info admonition includes trailing spaces (::: ). If the delimiter is not exactly :::, Docusaurus may not close the admonition correctly and the following content can be rendered inside the callout.

:::info

With the start of the Quality Assurance Phase, all review feedback becomes **normative**. Mandatory findings must be resolved before a standard can proceed. Standard candidates with unresolved mandatory findings are considered **not release-ready** and will be excluded from the release.

:::  

[jSchuetz88]

Should we update this list?

[jSchuetz88]

Suggested change

	Although both organizations manage their own release processes, the ecosystem release ensures that these artefacts are aligned and can be adopted together by ecosystem participants.
	Although the Catena-X Association and the Eclipse Tractus-X Project manage their own release processes, the ecosystem release ensures that these artefacts are aligned and can be adopted together by ecosystem participants.

Note: just nitpicking here, but Tractus-X is technically a project and not an organization.

[jSchuetz88]

Suggested change

	As part of the introduction of this new release process with the goal of achieving **operational excellence**, the **26.12 release was skipped**. As a result, **Proteus consists of only one release part, 27.03**.
	As part of the introduction of this new release process with our commitment to further elevate **operational excellence**, the **26.12 release was skipped**. As a result, **Proteus consists of only one release part, 27.03**.

Otherwise it sounds like, we don't have operational excellence yet.

[jSchuetz88]

Overall LGTM. Please consider my suggestion above.

The only blocker from my site are the linting errors. In my understand we need to add details and summary to MD033 in .markdownlint.json

[jSchuetz88]

Suggested change

	The Quality Assurance Phase represents the **central review and validation stage** of the Catena-X release cycle. With the start of this phase, the standard owners formally hand over their completed standards to the **TC4S (Technical Committee for Standardization)**, which assumes coordination of the entire review process up to the final release decision.
	The Quality Assurance Phase represents the **central review and validation stage** of the Catena-X release cycle. With the start of this phase, the standard owners formally hand over their completed standards drafts to the **TC4S (Technical Committee for Standardization)**, which assumes coordination of the entire review process up to the final release decision.

[jSchuetz88]

Suggested change

	From this point on, all standard candidates enter a **structured review and validation process**. Feedback can still be incorporated, but only in **close alignment with TC4S and the assigned reviewing experts**.
	From this point on, all standard drafts enter a **structured review and validation process**. Feedback can still be incorporated, but only in **close alignment with TC4S and the assigned reviewing experts**.

To my understanding, at this point the documents are just drafts, only after approval of QG 2 with entering the O'pt Out they become candidates?

[jSchuetz88]

Suggested change

	At the end of the phase, the **overarching committee formally confirms** that the standard fulfills the expectations defined by the responsible Expert Group and is ready to proceed to the next stage of the release process.
	At the end of the phase, the **overarching committee formally confirms** that the standard drafts fulfills the expectations defined by the responsible Expert Group and is ready to proceed to the next stage of the release process as standard candidates.

[jSchuetz88]

Suggested change

	With the start of the Quality Assurance Phase, all review feedback becomes **normative**. Mandatory findings must be resolved before a standard can proceed. Standard candidates with unresolved mandatory findings are considered **not release-ready** and will be excluded from the release.
	With the start of the Quality Assurance Phase, all findings must be resolved before a standard can proceed. Standard drafts with unresolved mandatory findings can not become standard candidates and are considered as **not release-ready**, which will be excluded from the release.

[jSchuetz88]

Suggested change

**Quality Gate 1** marks the first formal checkpoint within the Quality Assurance Phase. Its purpose is to ensure that only standard candidates aligned with the **values, goals, and quality principles** of the Catena-X data ecosystem proceed further in the release process. Each standard is systematically evaluated against defined criteria, focusing on **completeness, relevance, redundancy, and conformance**.

**Quality Gate 1** marks the first formal checkpoint within the Quality Assurance Phase. Its purpose is to ensure that only standard drafts aligned with the **values, goals, and quality requirements** of the Catena-X data ecosystem proceed further in the release process. Each standard is systematically evaluated against defined criteria, focusing on **completeness, relevance, redundancy, and conformance**.