From c8985f168240b9491a855fe8f0885169afa6c6ce Mon Sep 17 00:00:00 2001 From: Piotr Korkus Date: Mon, 2 Mar 2026 13:29:53 +0100 Subject: [PATCH 1/4] docs: release process documentation --- docs/how_to_release.rst | 60 +++++++++++++++++++++++++++++++++++++++++ docs/index.rst | 1 + 2 files changed, 61 insertions(+) create mode 100644 docs/how_to_release.rst diff --git a/docs/how_to_release.rst b/docs/how_to_release.rst new file mode 100644 index 00000000000..18341e539a3 --- /dev/null +++ b/docs/how_to_release.rst @@ -0,0 +1,60 @@ +================================= +How to create a release of S-CORE +================================= + +Definitions +----------- + +========================== ================================== +Role Description +========================== ================================== +Reference Integration Team Prepare integration process +Module Codeowners Prepare Module's release candidate +Project Manager Approves S-CORE release +========================== ================================== + +Process overview +---------------- +Release interval between S-CORE Product Increments can be divided into two phases: + +* development (4 weeks) +* integration (2 weeks) + +At the beginning, the overall scope and general requirements for the Modules are discussed and agreed upon within the S-CORE community, +providing clear goals for what must be achieved. + +During the development phase, work on new features and improvements to the Modules takes place. At the end of this period, each Module +must provide a hash of the commit that represents a *code freeze* and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch. + +The integration phase begins with the creation of a **release branch** in the ``reference_integration`` repository. +Module Codeowners prepare a Pull Request to that branch with updates to the ``known_good.json`` file, pointing to the hash of their *code freeze*. +They may update other JSON fields for their Module as needed. Automated workflows will build and test to provide clear feedback directly in the PR. +If there are any issues, Module Codeowners can either push fixes to their **dedicated release** branch and update the hash in the PR accordingly, +or provide patches (see :ref:`ref_int_patching-label`). + +Once all Modules are merged with their *code freeze*, Module Codeowners create a tag on that exact hash following the S-CORE release process, +provide release notes to the ``score_platform`` team, and ensure that the new release is present in S-CORE's ``bazel_registry``. +The Reference Integration Team prepares a final Pull Request and replaces all hashes with the dedicated release versions. +The Project Manager approves the PR, and the Reference Integration Team creates the new S-CORE release. + +An automated verification process of the release begins, and once successful, the release and its downloadable assets are ready for distribution. + +Fallbacks +--------- + +Module Codeowners may decide that their Module will not be released with a new major version for the S-CORE Product Increment. +However, they must ensure that the Module remains compatible with the S-CORE release and does not fail any workflows. + +If any S-CORE community member discovers a showstopper for the upcoming release, they must communicate it promptly to the Project Manager and other community members. +Following discussion and impact analysis, a decision is made regarding whether to postpone or skip the S-CORE release, and the planning is updated accordingly. + + +.. _ref_int_patching-label: + +Patching Module +--------------- + +Module Codeowners prepare ``.patch`` file(s) and place them in the ``/patches/MODULE_NAME`` directory. +The patch filename must clearly indicate what it addresses. +For multiple issues, it is preferred to create multiple patches rather than a single patch addressing all issues. +An empty Bazel ``BUILD`` file must be placed alongside the patches. diff --git a/docs/index.rst b/docs/index.rst index 188e48d8a8f..142a5038de8 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -66,3 +66,4 @@ Explore the documentation :glob: verification/* + how_to_release From b54eead0904c8de43bd96994888024699838b5cc Mon Sep 17 00:00:00 2001 From: Piotr Korkus Date: Mon, 2 Mar 2026 14:50:23 +0100 Subject: [PATCH 2/4] Update docs/how_to_release.rst apply suggestion Co-authored-by: Alexander Lanin Signed-off-by: Piotr Korkus --- docs/how_to_release.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/how_to_release.rst b/docs/how_to_release.rst index 18341e539a3..5f05c1e388d 100644 --- a/docs/how_to_release.rst +++ b/docs/how_to_release.rst @@ -42,7 +42,7 @@ An automated verification process of the release begins, and once successful, th Fallbacks --------- -Module Codeowners may decide that their Module will not be released with a new major version for the S-CORE Product Increment. +Module Codeowners may decide that their Module will not be released with a new version for the S-CORE Product Increment. However, they must ensure that the Module remains compatible with the S-CORE release and does not fail any workflows. If any S-CORE community member discovers a showstopper for the upcoming release, they must communicate it promptly to the Project Manager and other community members. From a31ef2ff81b835290f6280439acb022732725f29 Mon Sep 17 00:00:00 2001 From: Piotr Korkus Date: Tue, 3 Mar 2026 13:47:05 +0100 Subject: [PATCH 3/4] restructure document --- docs/how_to_release.rst | 150 ++++++++++++++++++++++++++++++++++------ 1 file changed, 127 insertions(+), 23 deletions(-) diff --git a/docs/how_to_release.rst b/docs/how_to_release.rst index 5f05c1e388d..0406f6b90db 100644 --- a/docs/how_to_release.rst +++ b/docs/how_to_release.rst @@ -5,48 +5,152 @@ How to create a release of S-CORE Definitions ----------- -========================== ================================== +========================== ==================================================== Role Description -========================== ================================== +========================== ==================================================== Reference Integration Team Prepare integration process Module Codeowners Prepare Module's release candidate -Project Manager Approves S-CORE release -========================== ================================== +Project Manager Guides the release process and leads decision making +========================== ==================================================== Process overview ---------------- + Release interval between S-CORE Product Increments can be divided into two phases: -* development (4 weeks) -* integration (2 weeks) +**Development phase (4 weeks) :** + +#. Common release requirements definition +#. Features' implemntations and improvements +#. Tooling release +#. Code freeze + +**Integration phase (2 weeks) :** + +#. Release branch creation +#. Integration of the Modules +#. Release candidate +#. Release creation + +Common release requirements definition +-------------------------------------- + +At the beginning, the overall scope and general requirements for the Modules are discussed and +agreed upon within the S-CORE community, providing clear goals for what must be achieved. +The scope should define requirements such as: + +* Tooling versions +* Used toolchains +* Supported platforms + +rather than specific features' implementation scopes. + +.. note:: + + Performed by: Project Manager and S-CORE community + +Features' implemntations and improvements +----------------------------------------- + +During the development phase, the community works on new features and improvements to the Modules. +Changes are reviewed by Commiters and Module Codeowners. + +.. note:: + + Performed by: S-CORE community and Module Codeowners + +Tooling release +--------------- + +S-CORE tools, toolchains and other dependencies are released at the end of the development phase the latest. +During the integration phase, no changes other than necessary bug fixes are allowed to give time to the Modules to rebase +their dependencies and prepare their *code freeze*. + +.. note:: + + Performed by: Module Codeowners + +Code freeze +----------- +At the end of development phase, each Module must provide a hash of the commit that represents a *code freeze* +and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch. -At the beginning, the overall scope and general requirements for the Modules are discussed and agreed upon within the S-CORE community, -providing clear goals for what must be achieved. +.. note:: -During the development phase, work on new features and improvements to the Modules takes place. At the end of this period, each Module -must provide a hash of the commit that represents a *code freeze* and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch. + Performed by: Module Codeowners -The integration phase begins with the creation of a **release branch** in the ``reference_integration`` repository. -Module Codeowners prepare a Pull Request to that branch with updates to the ``known_good.json`` file, pointing to the hash of their *code freeze*. -They may update other JSON fields for their Module as needed. Automated workflows will build and test to provide clear feedback directly in the PR. -If there are any issues, Module Codeowners can either push fixes to their **dedicated release** branch and update the hash in the PR accordingly, -or provide patches (see :ref:`ref_int_patching-label`). +Release branch creation +----------------------- + +The integration phase begins with the creation of a **release branch** in the ``reference_integration`` repository +originating from current **main**. + +.. note:: + + Performed by: Reference Integration Team + +Integration of the Modules +-------------------------- + +Module Codeowners prepare a Pull Request to that branch with updates to the ``known_good.json`` file, +pointing to the hash of their *code freeze*. They may update other JSON fields for their Module as needed. +Automated workflows will build and test to provide clear feedback directly in the PR. +If there are any issues, Module Codeowners can either push fixes to their **dedicated release** branch +and update the hash in the PR accordingly, or provide patches (see :ref:`ref_int_patching-label`). + +.. note:: + + Performed by: Module Codeowners + +Release candidate +----------------- Once all Modules are merged with their *code freeze*, Module Codeowners create a tag on that exact hash following the S-CORE release process, -provide release notes to the ``score_platform`` team, and ensure that the new release is present in S-CORE's ``bazel_registry``. +provide release notes to the ``score_platform`` repository, and ensure that the new release is present in S-CORE's ``bazel_registry``. The Reference Integration Team prepares a final Pull Request and replaces all hashes with the dedicated release versions. -The Project Manager approves the PR, and the Reference Integration Team creates the new S-CORE release. -An automated verification process of the release begins, and once successful, the release and its downloadable assets are ready for distribution. +This pull request has additional workflow checking that every Codeowner has approved the PR signing off their Module's release candidate. +There is an additional ``.rst`` file listing every Module and GitHub ID of the Codeowner responsible. +.. note:: + + Performed by: Reference Integration Team and Module Codeowners + +Release creation +---------------- + +Once all previous steps are completed Reference Integration Team triggers the release creation workflow in ``release_integration``. +An automated verification process of the release begins which includes building, testing, deploying documentation and checking that +every Module has been correctly signed-off by its Codeowner. If any issue is found, the release creation process is stopped. +When successfully completed the release and its downloadable assets are ready for distribution. + +.. note:: + + Performed by: Reference Integration Team + -Fallbacks ---------- +Opting out of a release +----------------------- Module Codeowners may decide that their Module will not be released with a new version for the S-CORE Product Increment. -However, they must ensure that the Module remains compatible with the S-CORE release and does not fail any workflows. +However, they must still ensure that the Module remains compatible with the S-CORE release and does not fail any workflows. + +If Module Codeowners cannot adapt to the newest release requirements or any S-CORE community member discovers a showstopper +for the upcoming release, they must communicate it promptly to the Project Manager and other community members. +Following discussion and impact analysis, a decision is made regarding whether to postpone or skip the S-CORE release, +and the planning is updated accordingly. + + +Removing Module from Reference Integration +------------------------------------------ + +Currently following modules can be removed without an impact on the S-CORE release: + +* ``score_feo`` +* ``score_orchestrator`` -If any S-CORE community member discovers a showstopper for the upcoming release, they must communicate it promptly to the Project Manager and other community members. -Following discussion and impact analysis, a decision is made regarding whether to postpone or skip the S-CORE release, and the planning is updated accordingly. +Once excluded from the release and integration issue persists also on a ``reference_integration`` **main** branch, +Reference Integration Team will remove the Module completely. +It is up to Module Codeowners to fix and integrate the Module back into the main branch and later releases. .. _ref_int_patching-label: From 7bd90b39682009f6811eacb9eff45a18113f4858 Mon Sep 17 00:00:00 2001 From: Piotr Korkus Date: Tue, 3 Mar 2026 19:47:43 +0100 Subject: [PATCH 4/4] review suggestions applied --- .../score_modules_tooling.MODULE.bazel | 2 +- docs/how_to_release.rst | 79 +++++++++++++------ known_good.json | 2 +- 3 files changed, 55 insertions(+), 28 deletions(-) diff --git a/bazel_common/score_modules_tooling.MODULE.bazel b/bazel_common/score_modules_tooling.MODULE.bazel index 78da008bc58..5507eca8260 100644 --- a/bazel_common/score_modules_tooling.MODULE.bazel +++ b/bazel_common/score_modules_tooling.MODULE.bazel @@ -38,7 +38,7 @@ git_override( bazel_dep(name = "score_platform") git_override( module_name = "score_platform", - commit = "bf8502071d750cb70d88f1cb5cfbf5e5e7407f27", + commit = "dc9930fe7e9bfcc5cbc89b85b287c3120b5e4f52", remote = "https://github.com/eclipse-score/score.git", ) diff --git a/docs/how_to_release.rst b/docs/how_to_release.rst index 0406f6b90db..38cdd892c8c 100644 --- a/docs/how_to_release.rst +++ b/docs/how_to_release.rst @@ -9,8 +9,8 @@ Definitions Role Description ========================== ==================================================== Reference Integration Team Prepare integration process -Module Codeowners Prepare Module's release candidate -Project Manager Guides the release process and leads decision making +Module Maintainers Prepare Module's release candidate +Project Lead Guides the release process and leads decision making ========================== ==================================================== Process overview @@ -18,10 +18,10 @@ Process overview Release interval between S-CORE Product Increments can be divided into two phases: -**Development phase (4 weeks) :** +**Development phase (6 weeks) :** #. Common release requirements definition -#. Features' implemntations and improvements +#. Features' implementations and improvements #. Tooling release #. Code freeze @@ -44,40 +44,50 @@ The scope should define requirements such as: * Supported platforms rather than specific features' implementation scopes. +Based on the operating system definitions documented in the `Operating Systems<_collections/score_platform/docs/modules/os/operating_systems/docs/index.html>`_ +the Reference Integration Team will only maintain functional/certifiable level OSs as part of the release, +while community OSs will be prepared and maintained by the OS module Maintainers. *Code freeze* applies to OSs as well. .. note:: - Performed by: Project Manager and S-CORE community + Performed by: Project Lead and S-CORE community Features' implemntations and improvements ----------------------------------------- During the development phase, the community works on new features and improvements to the Modules. -Changes are reviewed by Commiters and Module Codeowners. +Changes are reviewed by Commiters and Module Maintainers. .. note:: - Performed by: S-CORE community and Module Codeowners + Performed by: S-CORE community and Module Maintainers Tooling release --------------- -S-CORE tools, toolchains and other dependencies are released at the end of the development phase the latest. +S-CORE tools, toolchains and other dependencies which are listed in the following Bazel MODULE files: + +* ``bazel_common/score_gcc_toolchains.MODULE.bazel`` +* ``bazel_common/score_modules_tooling.MODULE.baze`` +* ``bazel_common/score_qnx_toolchains.MODULE.bazel`` +* ``bazel_common/score_rust_toolchains.MODULE.baze`` + +are released at the end of the development phase the latest. During the integration phase, no changes other than necessary bug fixes are allowed to give time to the Modules to rebase their dependencies and prepare their *code freeze*. .. note:: - Performed by: Module Codeowners + Performed by: Module Maintainers Code freeze ----------- At the end of development phase, each Module must provide a hash of the commit that represents a *code freeze* and serves as a candidate for integration. The hash can be from the **main** or **dedicated release** branch. - + .. note:: - Performed by: Module Codeowners + Performed by: Module Maintainers Release branch creation ----------------------- @@ -92,35 +102,36 @@ originating from current **main**. Integration of the Modules -------------------------- -Module Codeowners prepare a Pull Request to that branch with updates to the ``known_good.json`` file, +Module Maintainers prepare a Pull Request to that branch with updates to the ``known_good.json`` file, pointing to the hash of their *code freeze*. They may update other JSON fields for their Module as needed. Automated workflows will build and test to provide clear feedback directly in the PR. -If there are any issues, Module Codeowners can either push fixes to their **dedicated release** branch +If there are any issues, Module Maintainers can either push fixes to their **dedicated release** branch and update the hash in the PR accordingly, or provide patches (see :ref:`ref_int_patching-label`). .. note:: - Performed by: Module Codeowners + Performed by: Module Maintainers Release candidate ----------------- -Once all Modules are merged with their *code freeze*, Module Codeowners create a tag on that exact hash following the S-CORE release process, +Once all Modules are merged with their *code freeze*, Module Maintainers create a tag on that exact hash following the S-CORE release process, provide release notes to the ``score_platform`` repository, and ensure that the new release is present in S-CORE's ``bazel_registry``. The Reference Integration Team prepares a final Pull Request and replaces all hashes with the dedicated release versions. -This pull request has additional workflow checking that every Codeowner has approved the PR signing off their Module's release candidate. -There is an additional ``.rst`` file listing every Module and GitHub ID of the Codeowner responsible. +This pull request has additional workflow checking that every Maintainer has approved the PR signing off their Module's release candidate. +There is an additional ``.rst`` file listing every Module and GitHub ID of the Maintainer responsible. + .. note:: - Performed by: Reference Integration Team and Module Codeowners + Performed by: Reference Integration Team and Module Maintainers Release creation ---------------- Once all previous steps are completed Reference Integration Team triggers the release creation workflow in ``release_integration``. An automated verification process of the release begins which includes building, testing, deploying documentation and checking that -every Module has been correctly signed-off by its Codeowner. If any issue is found, the release creation process is stopped. +every Module has been correctly signed-off by its Maintainer. If any issue is found, the release creation process is stopped. When successfully completed the release and its downloadable assets are ready for distribution. .. note:: @@ -131,11 +142,12 @@ When successfully completed the release and its downloadable assets are ready fo Opting out of a release ----------------------- -Module Codeowners may decide that their Module will not be released with a new version for the S-CORE Product Increment. -However, they must still ensure that the Module remains compatible with the S-CORE release and does not fail any workflows. +Module Maintainers may decide that their Module will not be released with a new version for the S-CORE Product Increment. +In that case currently integrated version can be used. However, they must still ensure that the Module remains compatible with +the S-CORE release and does not fail any workflows. -If Module Codeowners cannot adapt to the newest release requirements or any S-CORE community member discovers a showstopper -for the upcoming release, they must communicate it promptly to the Project Manager and other community members. +If Module Maintainers cannot adapt to the newest release requirements or any S-CORE community member discovers a showstopper +for the upcoming release, they must communicate it promptly to the Project Lead and other community members. Following discussion and impact analysis, a decision is made regarding whether to postpone or skip the S-CORE release, and the planning is updated accordingly. @@ -150,7 +162,7 @@ Currently following modules can be removed without an impact on the S-CORE relea Once excluded from the release and integration issue persists also on a ``reference_integration`` **main** branch, Reference Integration Team will remove the Module completely. -It is up to Module Codeowners to fix and integrate the Module back into the main branch and later releases. +It is up to Module Maintainers to fix and integrate the Module back into the main branch and later releases. .. _ref_int_patching-label: @@ -158,7 +170,22 @@ It is up to Module Codeowners to fix and integrate the Module back into the main Patching Module --------------- -Module Codeowners prepare ``.patch`` file(s) and place them in the ``/patches/MODULE_NAME`` directory. +Module Maintainers prepare ``.patch`` file(s) and place them in the ``/patches/MODULE_NAME`` directory. The patch filename must clearly indicate what it addresses. For multiple issues, it is preferred to create multiple patches rather than a single patch addressing all issues. -An empty Bazel ``BUILD`` file must be placed alongside the patches. + +Target releases definition +-------------------------- + +Based on the operating system definitions documented in the `OS module `_, +the Reference Integration Team defines which OSs will be maintained as part of the release: + +* **Functional/Certifiable level OSs** - maintained by the Reference Integration Team and included in the release +* **Community OSs** - prepared and maintained by the OS module Maintainers during the integration phase + +Only changes to functional/certifiable level OSs are considered until the *code freeze*. +Community OS updates can be prepared by the OS Maintainer during the release phase if needed. + +.. note:: + + Performed by: Reference Integration Team and OS module Maintainers diff --git a/known_good.json b/known_good.json index f7299714b21..48b567de603 100644 --- a/known_good.json +++ b/known_good.json @@ -126,7 +126,7 @@ }, "score_platform": { "repo": "https://github.com/eclipse-score/score.git", - "hash": "bf8502071d750cb70d88f1cb5cfbf5e5e7407f27" + "hash": "dc9930fe7e9bfcc5cbc89b85b287c3120b5e4f52" }, "score_bazel_platforms": { "repo": "https://github.com/eclipse-score/bazel_platforms.git",