Skip to content

Commit a5bf59e

Browse files
PiotrKorkusPiotrKorkus
committed
add release process document
1 parent feb5923 commit a5bf59e

File tree

2 files changed

+227
-5
lines changed

2 files changed

+227
-5
lines changed

‎docs/platform_management_plan/index.rst‎

Lines changed: 3 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -36,6 +36,7 @@ Platform Management Plan
3636
config_management
3737
tool_management
3838
release_management
39+
release_process
3940
problem_resolution
4041
vulnerability_management
4142
change_management
@@ -45,10 +46,7 @@ Platform Management Plan
4546

4647
.. toctree::
4748
:titlesonly:
49+
:glob:
4850
:caption: Role Assignments
4951

50-
role_assignment/platform_safety_engineer
51-
role_assignment/platform_safety_manager
52-
role_assignment/platform_security_manager
53-
role_assignment/platform_quality_manager
54-
52+
role_assignment/*

‎docs/platform_management_plan/release_process.rst‎

Lines changed: 224 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,224 @@
1+
..
2+
# *******************************************************************************
3+
# Copyright (c) 2026 Contributors to the Eclipse Foundation
4+
#
5+
# See the NOTICE file(s) distributed with this work for additional
6+
# information regarding copyright ownership.
7+
#
8+
# This program and the accompanying materials are made available under the
9+
# terms of the Apache License Version 2.0 which is available at
10+
# https://www.apache.org/licenses/LICENSE-2.0
11+
#
12+
# SPDX-License-Identifier: Apache-2.0
13+
# *******************************************************************************
14+
15+
=================================
16+
How to create a release of S-CORE
17+
=================================
18+
19+
Definitions
20+
-----------
21+
22+
========================== =====================================================================
23+
Role Description
24+
========================== =====================================================================
25+
Reference Integration Team Prepare integration process
26+
Module Maintainers Prepare Module's release candidate
27+
Project Leads Guides the release process and leads decision making
28+
Quality Manager Ensures the release process is followed and quality standards are met
29+
========================== =====================================================================
30+
31+
Process overview
32+
----------------
33+
34+
Release interval between S-CORE Product Increments can be divided into two phases:
35+
36+
**Development phase (6 weeks) :**
37+
38+
#. Common release requirements definition
39+
#. Internal communication
40+
#. Features' implementations and improvements
41+
#. Tooling release
42+
#. Code freeze
43+
44+
**Integration phase (2 weeks) :**
45+
46+
#. Release branch creation
47+
#. Integration of the Modules
48+
#. Release notes
49+
#. Release candidate
50+
#. Release creation
51+
52+
Common release requirements definition
53+
--------------------------------------
54+
55+
At the beginning, the overall scope and general requirements for the Modules are discussed during
56+
Release Team Meeting and agreed upon within the S-CORE community, providing clear goals for what must be achieved.
57+
The scope should define minor requirements such as:
58+
59+
* Tooling versions
60+
* Used toolchains
61+
* Supported platforms
62+
63+
rather than specific features' implementation scopes.
64+
Full list of tools can be found in the :need:`doc__tool_evaluation_list`.
65+
The scope will be defined in Github issue with sub-issues for every participating Module to track progress.
66+
67+
Based on the operating system definitions documented in the :ref:`comp_doc_os`
68+
the Reference Integration Team will only maintain functional/certifiable level OSs as part of the release,
69+
while community OSs will be prepared and maintained by the OS module Maintainers. *Code freeze* applies to OSs as well.
70+
71+
.. note::
72+
73+
Performed by: Project Leads and S-CORE community
74+
75+
76+
Internal Communication
77+
----------------------
78+
79+
Project Leads present scope during Tech Alignment call for final discussion and then send a communication
80+
via mailing list to inform about the scope of upcomming release.
81+
82+
.. note::
83+
84+
Performed by: Project Leads
85+
86+
Features' implementations and improvements
87+
------------------------------------------
88+
89+
During the development phase, the community works on new features and improvements to the Modules.
90+
Changes are reviewed by Commiters and Module Maintainers.
91+
92+
.. note::
93+
94+
Performed by: S-CORE community and Module Maintainers
95+
96+
Tooling release
97+
---------------
98+
99+
S-CORE tools, toolchains and other dependencies which are listed in the following Bazel MODULE files
100+
located in reference integration repository:
101+
102+
* ``bazel_common/score_gcc_toolchains.MODULE.bazel``
103+
* ``bazel_common/score_modules_tooling.MODULE.bazel``
104+
* ``bazel_common/score_qnx_toolchains.MODULE.bazel``
105+
* ``bazel_common/score_rust_toolchains.MODULE.bazel``
106+
107+
are released at the end of the development phase the latest.
108+
During the integration phase, no changes other than necessary bug fixes are allowed to give time to the Modules to rebase
109+
their dependencies and prepare their *code freeze*.
110+
111+
.. note::
112+
113+
Performed by: Module Maintainers
114+
115+
Code freeze
116+
-----------
117+
At the end of development phase, each Module must provide a hash of the commit that represents a *code freeze*
118+
and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch.
119+
120+
.. note::
121+
122+
Performed by: Module Maintainers
123+
124+
Release branch creation
125+
-----------------------
126+
127+
The integration phase begins with the creation of a **release branch** in the ``reference_integration`` repository
128+
originating from current **main**.
129+
130+
.. note::
131+
132+
Performed by: Reference Integration Team
133+
134+
Integration of the Modules
135+
--------------------------
136+
137+
Module Maintainers prepare a Pull Request to that branch with updates to the ``known_good.json`` file,
138+
pointing to the hash of their *code freeze*. They may update other JSON fields for their Module as needed.
139+
Automated workflows will build and test to provide clear feedback directly in the PR.
140+
If there are any issues, Module Maintainers can either push fixes to their **dedicated release** branch
141+
and update the hash in the PR accordingly, or provide patches (see :ref:`ref_int_patching-label`).
142+
143+
.. note::
144+
145+
Performed by: Module Maintainers
146+
147+
Release notes
148+
-------------
149+
150+
Project Leads create a branch ``release/version`` with new release notes in ``score_platform`` repository following template: :need:`doc__platform_release_note`.
151+
Module Maintainers create a Pull Request to that branch with updates to the release notes,
152+
describing the changes in their Module for the release.
153+
Once all Modules are updated Project Leads approve the release notes and create ``score_platform`` release.
154+
155+
.. note::
156+
157+
Performed by: Module Maintainers and Project Leads
158+
159+
Release candidate
160+
-----------------
161+
162+
Once all Modules are merged with their *code freeze*, Module Maintainers create a tag on that exact hash following the S-CORE release process,
163+
and ensure that the new release is present in S-CORE's ``bazel_registry``.
164+
The Reference Integration Team prepares a final Pull Request and replaces all hashes with the dedicated release versions.
165+
166+
This pull request has additional workflow checking that every Maintainer has approved the PR signing off their Module's release candidate.
167+
Quality, Safety and Security are validated by dedicated Managers and their approval is required as well.
168+
There is an additional ``.rst`` file listing every Module and GitHub ID of the Maintainer responsible.
169+
170+
.. note::
171+
172+
Performed by: Reference Integration Team and Module Maintainers
173+
174+
Release creation
175+
----------------
176+
177+
Once all previous steps are completed Reference Integration Team triggers the release creation workflow in ``release_integration``.
178+
An automated verification process of the release begins which includes building, testing, deploying documentation and checking that
179+
every Module has been correctly signed-off by its Maintainer. If any issue is found, the release creation process is stopped.
180+
Once the process is aborted, the Reference Integration Team investigates the issue and works with the relevant Module Maintainer to fix it
181+
or if the issue is severe decides, together with the Project Leads, to postpone the release. If the issue is fixed, the release creation process can be triggered again.
182+
When successfully completed the release and its downloadable assets are ready for distribution.
183+
184+
.. note::
185+
186+
Performed by: Reference Integration Team
187+
188+
189+
Opting out of a release
190+
-----------------------
191+
192+
Module Maintainers may decide that their Module will not be released with a new version for the S-CORE Product Increment.
193+
In that case currently integrated version can be used. However, they must still ensure that the Module remains compatible with
194+
the S-CORE release and does not fail any workflows.
195+
196+
If Module Maintainers cannot adapt to the newest release requirements or any S-CORE community member discovers a showstopper
197+
for the upcoming release, they must communicate it promptly to the Project Leads and other community members.
198+
Following discussion and impact analysis, a decision is made regarding whether to postpone or skip the S-CORE release,
199+
and the planning is updated accordingly.
200+
201+
.. _ref_int_patching-label:
202+
203+
Patching Module
204+
---------------
205+
206+
Module Maintainers prepare ``.patch`` file(s) and place them in the ``/patches/MODULE_NAME`` directory.
207+
The patch filename must clearly indicate what it addresses.
208+
For multiple issues, it is preferred to create multiple patches rather than a single patch addressing all issues.
209+
210+
Target releases definition
211+
--------------------------
212+
213+
Based on the operating system definitions documented in the `OS module <https://eclipse-score.github.io/score/main/modules/os/operating_systems/docs/index.html>`_,
214+
the Reference Integration Team defines which OSs will be maintained as part of the release:
215+
216+
* **Functional/Certifiable level OSs** - maintained by the Reference Integration Team and included in the release
217+
* **Community OSs** - prepared and maintained by the OS module Maintainers during the integration phase
218+
219+
Only changes to functional/certifiable level OSs are considered until the *code freeze*.
220+
Community OS updates can be prepared by the OS Maintainer during the release phase if needed.
221+
222+
.. note::
223+
224+
Performed by: Reference Integration Team and OS module Maintainers

0 commit comments

Comments
 (0)