You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Release interval between S-CORE Product Increments can be divided into two phases:
20
20
21
-
**Development phase (4 weeks) :**
21
+
**Development phase (6 weeks) :**
22
22
23
23
#. Common release requirements definition
24
-
#. Features' implemntations and improvements
24
+
#. Features' implementations and improvements
25
25
#. Tooling release
26
26
#. Code freeze
27
27
@@ -44,40 +44,50 @@ The scope should define requirements such as:
44
44
* Supported platforms
45
45
46
46
rather than specific features' implementation scopes.
47
+
Based on the operating system definitions documented in the `Operating Systems<_collections/score_platform/docs/modules/os/operating_systems/docs/index.html>`_
48
+
the Reference Integration Team will only maintain functional/certifiable level OSs as part of the release,
49
+
while community OSs will be prepared and maintained by the OS module Maintainers. *Code freeze* applies to OSs as well.
47
50
48
51
.. note::
49
52
50
-
Performed by: Project Manager and S-CORE community
53
+
Performed by: Project Lead and S-CORE community
51
54
52
55
Features' implemntations and improvements
53
56
-----------------------------------------
54
57
55
58
During the development phase, the community works on new features and improvements to the Modules.
56
-
Changes are reviewed by Commiters and Module Codeowners.
59
+
Changes are reviewed by Commiters and Module Maintainers.
57
60
58
61
.. note::
59
62
60
-
Performed by: S-CORE community and Module Codeowners
63
+
Performed by: S-CORE community and Module Maintainers
61
64
62
65
Tooling release
63
66
---------------
64
67
65
-
S-CORE tools, toolchains and other dependencies are released at the end of the development phase the latest.
68
+
S-CORE tools, toolchains and other dependencies which are listed in the following Bazel MODULE files:
are released at the end of the development phase the latest.
66
76
During the integration phase, no changes other than necessary bug fixes are allowed to give time to the Modules to rebase
67
77
their dependencies and prepare their *code freeze*.
68
78
69
79
.. note::
70
80
71
-
Performed by: Module Codeowners
81
+
Performed by: Module Maintainers
72
82
73
83
Code freeze
74
84
-----------
75
85
At the end of development phase, each Module must provide a hash of the commit that represents a *code freeze*
76
86
and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch.
77
-
87
+
78
88
.. note::
79
89
80
-
Performed by: Module Codeowners
90
+
Performed by: Module Maintainers
81
91
82
92
Release branch creation
83
93
-----------------------
@@ -92,35 +102,36 @@ originating from current **main**.
92
102
Integration of the Modules
93
103
--------------------------
94
104
95
-
Module Codeowners prepare a Pull Request to that branch with updates to the ``known_good.json`` file,
105
+
Module Maintainers prepare a Pull Request to that branch with updates to the ``known_good.json`` file,
96
106
pointing to the hash of their *code freeze*. They may update other JSON fields for their Module as needed.
97
107
Automated workflows will build and test to provide clear feedback directly in the PR.
98
-
If there are any issues, Module Codeowners can either push fixes to their **dedicated release** branch
108
+
If there are any issues, Module Maintainers can either push fixes to their **dedicated release** branch
99
109
and update the hash in the PR accordingly, or provide patches (see :ref:`ref_int_patching-label`).
100
110
101
111
.. note::
102
112
103
-
Performed by: Module Codeowners
113
+
Performed by: Module Maintainers
104
114
105
115
Release candidate
106
116
-----------------
107
117
108
-
Once all Modules are merged with their *code freeze*, Module Codeowners create a tag on that exact hash following the S-CORE release process,
118
+
Once all Modules are merged with their *code freeze*, Module Maintainers create a tag on that exact hash following the S-CORE release process,
109
119
provide release notes to the ``score_platform`` repository, and ensure that the new release is present in S-CORE's ``bazel_registry``.
110
120
The Reference Integration Team prepares a final Pull Request and replaces all hashes with the dedicated release versions.
111
121
112
-
This pull request has additional workflow checking that every Codeowner has approved the PR signing off their Module's release candidate.
113
-
There is an additional ``.rst`` file listing every Module and GitHub ID of the Codeowner responsible.
122
+
This pull request has additional workflow checking that every Maintainer has approved the PR signing off their Module's release candidate.
123
+
There is an additional ``.rst`` file listing every Module and GitHub ID of the Maintainer responsible.
124
+
114
125
.. note::
115
126
116
-
Performed by: Reference Integration Team and Module Codeowners
127
+
Performed by: Reference Integration Team and Module Maintainers
117
128
118
129
Release creation
119
130
----------------
120
131
121
132
Once all previous steps are completed Reference Integration Team triggers the release creation workflow in ``release_integration``.
122
133
An automated verification process of the release begins which includes building, testing, deploying documentation and checking that
123
-
every Module has been correctly signed-off by its Codeowner. If any issue is found, the release creation process is stopped.
134
+
every Module has been correctly signed-off by its Maintainer. If any issue is found, the release creation process is stopped.
124
135
When successfully completed the release and its downloadable assets are ready for distribution.
125
136
126
137
.. note::
@@ -131,11 +142,12 @@ When successfully completed the release and its downloadable assets are ready fo
131
142
Opting out of a release
132
143
-----------------------
133
144
134
-
Module Codeowners may decide that their Module will not be released with a new version for the S-CORE Product Increment.
135
-
However, they must still ensure that the Module remains compatible with the S-CORE release and does not fail any workflows.
145
+
Module Maintainers may decide that their Module will not be released with a new version for the S-CORE Product Increment.
146
+
In that case currently integrated version can be used. However, they must still ensure that the Module remains compatible with
147
+
the S-CORE release and does not fail any workflows.
136
148
137
-
If Module Codeowners cannot adapt to the newest release requirements or any S-CORE community member discovers a showstopper
138
-
for the upcoming release, they must communicate it promptly to the Project Manager and other community members.
149
+
If Module Maintainers cannot adapt to the newest release requirements or any S-CORE community member discovers a showstopper
150
+
for the upcoming release, they must communicate it promptly to the Project Lead and other community members.
139
151
Following discussion and impact analysis, a decision is made regarding whether to postpone or skip the S-CORE release,
140
152
and the planning is updated accordingly.
141
153
@@ -150,15 +162,30 @@ Currently following modules can be removed without an impact on the S-CORE relea
150
162
151
163
Once excluded from the release and integration issue persists also on a ``reference_integration`` **main** branch,
152
164
Reference Integration Team will remove the Module completely.
153
-
It is up to Module Codeowners to fix and integrate the Module back into the main branch and later releases.
165
+
It is up to Module Maintainers to fix and integrate the Module back into the main branch and later releases.
154
166
155
167
156
168
.. _ref_int_patching-label:
157
169
158
170
Patching Module
159
171
---------------
160
172
161
-
Module Codeowners prepare ``.patch`` file(s) and place them in the ``/patches/MODULE_NAME`` directory.
173
+
Module Maintainers prepare ``.patch`` file(s) and place them in the ``/patches/MODULE_NAME`` directory.
162
174
The patch filename must clearly indicate what it addresses.
163
175
For multiple issues, it is preferred to create multiple patches rather than a single patch addressing all issues.
164
-
An empty Bazel ``BUILD`` file must be placed alongside the patches.
176
+
177
+
Target releases definition
178
+
--------------------------
179
+
180
+
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>`_,
181
+
the Reference Integration Team defines which OSs will be maintained as part of the release:
182
+
183
+
* **Functional/Certifiable level OSs** - maintained by the Reference Integration Team and included in the release
184
+
* **Community OSs** - prepared and maintained by the OS module Maintainers during the integration phase
185
+
186
+
Only changes to functional/certifiable level OSs are considered until the *code freeze*.
187
+
Community OS updates can be prepared by the OS Maintainer during the release phase if needed.
188
+
189
+
.. note::
190
+
191
+
Performed by: Reference Integration Team and OS module Maintainers
0 commit comments