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 new file mode 100644 index 00000000000..38cdd892c8c --- /dev/null +++ b/docs/how_to_release.rst @@ -0,0 +1,191 @@ +================================= +How to create a release of S-CORE +================================= + +Definitions +----------- + +========================== ==================================================== +Role Description +========================== ==================================================== +Reference Integration Team Prepare integration process +Module Maintainers Prepare Module's release candidate +Project Lead Guides the release process and leads decision making +========================== ==================================================== + +Process overview +---------------- + +Release interval between S-CORE Product Increments can be divided into two phases: + +**Development phase (6 weeks) :** + +#. Common release requirements definition +#. Features' implementations 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. +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 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 Maintainers. + +.. note:: + + Performed by: S-CORE community and Module Maintainers + +Tooling release +--------------- + +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 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 Maintainers + +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 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 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 Maintainers + +Release candidate +----------------- + +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 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 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 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:: + + Performed by: Reference Integration Team + + +Opting out of a release +----------------------- + +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 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. + + +Removing Module from Reference Integration +------------------------------------------ + +Currently following modules can be removed without an impact on the S-CORE release: + +* ``score_feo`` +* ``score_orchestrator`` + +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 Maintainers to fix and integrate the Module back into the main branch and later releases. + + +.. _ref_int_patching-label: + +Patching Module +--------------- + +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. + +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/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 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",