docs: add initial release process description skeleton #519
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,81 @@ | ||
| # Release and Roadmap Process | ||
|
|
||
| We follow a coordinated approach to plan improvements of Eclipse Tractus-X. See also [Open Planning and Refinement](open-refinement-and-planning.md). | ||
|
|
||
| While every repository in the [eclipse-tractusx](https://github.com/eclipse-tractusx) GitHub organization | ||
| has its own issue management, the [Release Planning Board](https://github.com/orgs/eclipse-tractusx/projects/26) | ||
| is used to align the overarching Tractus-X releases. | ||
|
|
||
| ### How can I get involved | ||
|
|
||
| In case you experienced a bug, unexpected behaviour, or you want to propose enhancements to Eclipse Tractus-X, | ||
| feel free to use one of the provided [issue templates](https://github.com/eclipse-tractusx/sig-release/issues/new/choose) and describe your request. | ||
| Please be aware, that not every feature request can be integrated and that we also cannot treat every issue with the highest priority. | ||
|
|
||
| Every Release planning will be kicked off by two public alignment sessions. The dates and further details will be shared via | ||
| [tractusx-dev](https://accounts.eclipse.org/mailing-list/tractusx-dev) mailing list. | ||
| In addition to that, you can also find public meetings and info about how to join on our | ||
| [Open Meetings](https://eclipse-tractusx.github.io/community/open-meetings) community page. | ||
| Issues or bug reports, that should be discussed in these meetings, have to be opened prior to the meeting via | ||
| our [issue templates](https://github.com/eclipse-tractusx/sig-release/issues/new/choose). | ||
|
|
||
| ### What can I expect | ||
|
|
||
| We really welcome every contribution. Every Bug report and feature proposal takes time to prepare, | ||
| is valuable to our project, and we very much appreciate this input. | ||
| We are giving our best to give a first feedback in one week. | ||
| If we should miss that, please stick with us and just use the commenting function to remind us of the issue. | ||
|
|
||
| ### Issue structure | ||
|
|
||
| Our issues do have important properties, that enable our planning process. These are: | ||
|
|
||
| - __Labels:__ We use them to indicate the involved teams (kit or foss component). A label for each involved component is added to an issue | ||
SebastianBezold marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - __Issue Type:__ To separate between bugs, feature requests and release criteria, we use a custom field `Issue Type` | ||
| - __Milestone:__ Every Tractus-X release is represented by a `Milestone`. You can use this field to get a rough idea about the ETA | ||
|
|
||
| - __Status:__ The status field is used to integrate the progress of an issue | ||
|
|
||
| ### Issue statuses | ||
|
|
||
| The following statuses are defined: | ||
|
|
||
| - __Inbox:__ This is the initial status of all issues. It indicates, that involved components have to be identified and additional information gathered | ||
| - __Backlog:__ If enough information is gathered, and we agreed to work on the issue, it is set from `Inbox` to `Backlog` to indicate it is ready for timeline planning | ||
| - __Work in Progress:__ The issue is actively being worked on. | ||
| - __Done:__ All relevant parts have been implemented and released | ||
|
|
||
| ### Issue process | ||
|
|
||
|
There was a problem hiding this comment. This is done by every team individually. There was a problem hiding this comment. Definitely good point, but the |
||
| Every new feature proposal or bug report will be handled as issue in status `Inbox` initially. The alignment meetings are used to discuss the purpose and impact of the current issues. | ||
| While in `Inbox` status, the involved components are discovered and respective `Labels` are added. If already possible, a desired `Milestone` can be set. | ||
|
|
||
| Additionally, an `Assignee` is selected, who will coordinate efforts to solve the issue. | ||
|
|
||
| After these details are clarified, an issue is moved to `Backlog` to open it for detailed timeline planning. In this status, discussions about a fitting `Iteration` is held. | ||
|
There was a problem hiding this comment. The fully refined status "backlog" is the entry point for our "open planning" ceremony. |
||
|
|
||
| As soon as actual work is started in the selected iteration, the issue is set to `Work in Progress`. This is especially helpful on our project milestone views to get an overview of the release progress. | ||
|
|
||
| The final status `Done` is set, as soon as all relevant implementations are done, tested and released. This has to be achieved for every change in every involved component. | ||
|
|
||
|
There was a problem hiding this comment. add new section: |
||
| ### Planning component changes | ||
|
|
||
| While the [Release Planning Board](https://github.com/orgs/eclipse-tractusx/projects/26) is used to coordinate overarching feature and bug requests, | ||
| we encourage every component team to break these issues down to their component repositories/projects. | ||
| When doing so, make sure you link to the overarching issue in your component issue description. | ||
|
|
||
| ## Release Management Acceptance Criteria | ||
|
There was a problem hiding this comment. IMHO everything from here on is not confirmed yet |
||
|
|
||
| The release participation can be initiated by creating issues for the acceptance criteria check from the Issue templates. | ||
| Each release the templates for the acceptance criteria will be renewed. There are two paths for processing the acceptance criteria for an application team to participate in a release. | ||
|
|
||
| ### The Release Happy Path for the Acceptance Criteria | ||
|
|
||
| The three process steps to get to the status you need to pass the Q-Gate are shown in the happy path process flow. | ||
|
|
||
| Each acceptance criteria issue in GitHub contains a note with the prime contacts so that it is clear who is the assigned expert or release manager. | ||
|
|
||
|  | ||
|
|
||
| ### The other Release Path | ||
|
|
||
| If the evidence is not sufficient so that the criterium can not be accepted in the quality gate (QG), obligations for the product team will be defined to make a reassessment. | ||
|  | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,44 @@ | ||
| # Product Release | ||
|
There was a problem hiding this comment. Maybe it's worth mentioning that products have their release processes and to refer to the according product specific repositories for information about those. |
||
|
|
||
| Tractus-X products do follow their own release process. Please check the leading product repositories for details. | ||
| Independent of the technical details of product release processes, the released artifacts and minimum level of quality ensurance | ||
|
|
||
| is the same across all of them. | ||
|
|
||
| The release contents for individual products are are planned in the [open refinement and planning](./open-refinement-and-planning.md) sessions. | ||
|
|
||
| These sessions define the scope for all dataspace components, but therefore paint a clear picture of enhancements necessary for every single product. | ||
|
|
||
| The product teams themselfes are then responsible to define fine-grained task breakdowns as suiting their own needs. | ||
|
|
||
|
|
||
| > __HINT:__ | ||
| > If product enhancements contribute to an overarching dataspace feature, please link the dataspace feature defined in `sig-release` in your product issue. | ||
| > These links can be done in either the description or any comment on your issue. Use `eclipse-tractusx/sig-release#issue-number` | ||
|
|
||
| Once planning activities for a certain iteration are completed, the implementation phase is starting and product teams can coordinate, where necessary | ||
| through our [communication channels](https://eclipse-tractusx.github.io/docs/oss/getting-started#communication-channels). | ||
|
|
||
| Integration tests are performed by maintaining an umbrella Chart, that deploys all relevant dataspace components to spin up an artificial dataspace based on Tractus-X components. | ||
|
There was a problem hiding this comment. is "Product Umbrella Chart" now the best term based on conversation below? |
||
| There is a dedicated repository [eclipse-tractusx/tractus-x-umbrella](https://github.com/eclipse-tractusx/tractus-x-umbrella), that is maintained collectively to reflect the latest product release versions. | ||
|
|
||
| Additional to the integration- and unit-test suites the teams maintain, every product also needs to adhere to the [Tractus-X release guidelines (TRGs)](https://eclipse-tractusx.github.io/docs/release). | ||
|
There was a problem hiding this comment. Proposal for line 21: Every product needs to adhere... |
||
| Compliance to these guidelines __should__ be verified on every PR, but __must__ be complied with, as soon as a new product version is planned to be included in the Tractus-X release. | ||
|
|
||
| > __HINT:__ | ||
| > Take special care about legal requirements defined in TRG 7. They __must__ be adhered to on every PR. | ||
|
|
||
| Product releases are done by creating a GitHub release. Every release is following the [semantic versioning](https://semver.org/) pattern and marked in the git history via tag. | ||
|
|
||
| If suitable for the product teams development process, release candidate versions can help to provide early previews of a product for integration testing. | ||
|
|
||
| ## Artifacts | ||
|
|
||
| - GitHub release (Changelog + Sourcecode) | ||
| - Container images | ||
| - Helm Chart | ||
|
There was a problem hiding this comment. shall we call these "Product Helm Chart" => to differentiate from "Umbrella HC" in TX-Release? There was a problem hiding this comment. Product Helm Chart with Dependencies There was a problem hiding this comment. Would "Helm Chart (referred to as product Chart)" be fine?. |
||
|
|
||
| ## Versioning | ||
|
|
||
| - Semantic Versioning | ||
|
|
||
| ## Quality Assurance | ||
|
|
||
| - Defined in TRGs | ||
| - Responsibility of every contributor | ||
| - (Additonally verified in quality gate process. TBD, if kept after consortia) | ||
|
There was a problem hiding this comment. Typo in Additonally but mainly I'd not mention consortia, may just: |
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,38 @@ | ||
| # Tractus-X Release | ||
|
|
||
|
There was a problem hiding this comment. suggestion: ##Intro There was a problem hiding this comment. From my point of view, the E2E and Security part need to be clarified. So in my opinion, we need to find some middle ground for what is actually supported by Tractus-X and what is a Process driven by other players, like the Catena-X association or others, that is maybe to a certain extend supported by Tractus-X contributors and committers There was a problem hiding this comment. correct - but what we try to describe here is future target condition (to give guidance). |
||
| The Tractus-X release process aims to ensure compatibility of Tractus-X components and defines | ||
| and defines common quality criteria. Releases are initiated on a quarterly basis. | ||
| The desired enhancement of the dataspace functionality is planned in the [open refinement and planning](open-refinement-and-planning.md) sessions. | ||
| Past release documention can be found in [eclipse-tractusx/tractus-x-release](https://github.com/eclipse-tractusx/tractus-x-release). | ||
|
|
||
| To be included in a Tractus-X release, products __must__ opt-in to the process. | ||
| This is done by requesting a release review 4 weeks prior to the planned release date, using the "Product Release Check" [issue template](https://github.com/eclipse-tractusx/sig-release/issues/new/choose). | ||
|
|
||
| <!-- | ||
| TODO: | ||
| - technical steps to verify compatibility. Who is doing what? | ||
| - TRG checks | ||
| - e2e? | ||
| - CHANGELOG sounding (are dataspace feature mentionend and properly linked) | ||
| --> | ||
|
|
||
| ## Artifacts | ||
|
|
||
| - Changelog (overarching features) | ||
| - Umbrella Helm Chart(s) | ||
| - Overarching architecture documentation (if available) | ||
|
|
||
| ## Versioning | ||
|
|
||
| - Calendar versioning | ||
|
|
||
| ## Process | ||
|
|
||
| <!-- How are products (considered to be) integrated in the Tractus-X release --> | ||
| - Prior to release, a Tractus-X umbrella Chart release candidate branch is created | ||
| - Producs issue PRs with their release candidate | ||
|
There was a problem hiding this comment. This should be the future process, right? currently that's not happening and maybe that should be mentioned. There was a problem hiding this comment. Yes exactly, that's why I opened this draft PR. Jumpstarting this discussion is highly needed in my opinion. Right now, I don't really find the time to continue working on the draft |
||
|
|
||
|
There was a problem hiding this comment. abstractOnce feature work on product level is initiated, the quality assurance runs in parallel. The vehicle of Umbrella helm charts is used to continuously test pre-defined product bundles. There was a problem hiding this comment. Good input. I'll see if I can form that to specific sections once I finally find some time for it again. I will try to avoid some of the terms you used though. Some are not (yet) known in Eclipse Tractus-X and would need too much explanation. I.e.: There was a problem hiding this comment. cxOS may not yet be fully specified-out, but is mentioned and described by the association in the following zwo (maybe more) documents. So referencing without re-specification should be ok. There was a problem hiding this comment. the pictogram of "onion rings" shall be published near term, also via association, with regards to test management. will add the link here as soon as available. @danielmiehle any additional info? There was a problem hiding this comment. carry-over: in every quarterly TX release, we shall expect evolutions (new versions) of some cxOS components, There was a problem hiding this comment. text suggestion @stephanbcbauer & @RolaH1t 21-Mar: Note: In every quarterly TX release, we shall expect evolutions (new versions) of some components (see "product_release.md"). But also some other components may NOT face a change/up-revision in the given iteration. Nevertheless those components are still essential parts of the bundle. Example for cxOS (https://catena-x.net/fileadmin/_online_media_/231006_Whitepaper_Tractus-X.pdf (https://catena-x.net/fileadmin/_online_media_/231006_Whitepaper_Tractus-X.pdf): Additionally, manual e2e tests may apply. Environment and execution tbd. There was a problem hiding this comment. I get the idea of this description, but to me it almost seems like this is talking a different language, than I would expect from this process definition. As general suggestion for wording, I would avoid terms, that are unknown, undefined or not commonly used. |
||
| ### Quality Assurance | ||
|
|
||
| - User Journey tests (e2e) defined in e2e-testing repo | ||
| - User Journey tests automatically executed via `helm test` (nightly + on every product rc PR) | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest adding in a new paragraph:
Release Cycle - major vs. minor release
Tractus-X operates on a quarterly release cycle. Each quarter, a new Tractus-X release tractus-x-release.md following CalVer is released. Each Tractus-X release contains multiple products product_release.md Once per year, Tractus-X releases a major release, making the remaining three releases minor releases. A major release may contain critical breaking changes that have a major impact on data space participants,
such as changes to enablement services. A minor release contains backward compatible functionality. In addition, patch versions provide backward compatible bug and security fixes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @HFocken,
I also heard that, but actually never saw that in a tangible way.
At least "major" and "minor" is not directly visible in CalVer numbers as it would be in SemVer. Is it always the last release of a year, that will contain breaking changes?
How is this ensured in the planning process? Do issues from open planning also contain something that makes that transparent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Never heard of this too. Definitly something we should highlight more in our Release Notes @RolaH1t
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use text here AND on github.io page to initially introduce users to process.
add picture of phases.