Skip to content

Commit 235e08a

Browse files
PiotrKorkusPiotrKorkus
committed
add release process document
1 parent 321eecc commit 235e08a

File tree

3 files changed

+229
-5
lines changed

3 files changed

+229
-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/project_management.rst‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -320,6 +320,8 @@ Every software module project, located in another repository, is free to define
320320
additionally its own labels. It is recommended to create labels at least
321321
for specific areas that may encompass multiple features.
322322

323+
.. _pmp_types_of_work_packages_and_structure:
324+
323325
Types of work packages and structure
324326
------------------------------------
325327
For better structuring of the tickets following *GitHub Issue* types are introduced

‎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 (see :ref:`pmp_types_of_work_packages_and_structure`) 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)