Prepare s-core v0.5 alpha release

[antonkri]

Following activities should be done as preparation for release s-core v0.5 alpha (Due Date: 11.11.2025)

General

• Agree on the scope of s-core release, which modules exactly should be released
  • baselibs (FT), persistency (FT), communication (FT), score_platform (TLs), docs-as-code (Infra), toolchains (Infra), process_description (Process), reference_integration (TLs), bazel_registry (Infra), bazel_platforms (Infra), example/scrample repository (Anton), orchestration (draft) (FT), itf (Testing), score-test-scenario (Testing).
  • check if the modules are matching each other, e.g. docs-as-code and process repos
  • create a separate meeting for FTs at least to review the bazel registry PRs for Thursday/Friday.
• Set-up codeowners on the bazel registry repository, so that modules can be only added if reviewed by TL and safety manager (as we want to ensure, that merge is possible only if I-Gate is enabled and requirements and architecture is there).
  • @FScholPer
• Set-up a PR template, where first it should be explicitly acknowledged, that points from above are fulfilled before the PR is merged
  • Check if the PR is created automatically -> is the case. Needs solution
  • If not, @FScholPer will create a small template -> created as backup: added new pr template bazel_registry#141
• Prepare release description, e.g. https://eclipse-score.github.io/score/pr-1929/score_releases/index.html# @antonkri
• Provide a "score book", that describes s-core project and has a step-by-step tutorial to set-up first module, add it to the reference integration and execute in QNX QEMU
  • Reviewers: @FScholPer , @qor-lb, @DanielSteinkeSDV

Every module (create separate tickets)

• configured PR or/and release workflows with successful execution of at least following actions: gcc/qcc compilation, execution of unit-tests
• feature architecture and feature requirements described in main score repository
• component requirements, component architecture and preliminary component aous defined in module repository
  • every module has a one pager: for this release only reference integration as a golden example, @antonkri
• release notes, having short description of the provided functionality as comment in the release tag of the module
• More extensive description in the release description, e.g. https://eclipse-score.github.io/score/pr-1929/score_releases/index.html#

Reference integration

• We handle reference integration module as any other module

• Put a tarball with generated documentation @antonkri

• Prepare release notes for release s-core v0.5-alpha, including listing of all included modules and their release notes

• Demo applications

  • Create a demo application, that references majority of s-core v0.5 modules and runs in QNX QEMU. (@antonkri )
  • Linux: @odra will create a pr to the reference integration repository.
    • @odra will also provide a GitHub Action workflow to build linux image with lola and baselibs
  • Rust? Could we use same qnx_qemu module or do we need another one?

• Evtl. same demo application running on raspberry pi

Release notes template

• Overview of existing features, e.g. link or copy-paste from Readme
• What is included, e.g. requirements, code, tests
• Known limitations or bugs
• TODO: put it somewhere in the process documentation @masc2023

[FScholPer]

https://github.com/orgs/eclipse-score/discussions/1283

[FScholPer]

Safety Managers: https://github.com/orgs/eclipse-score/discussions/1119

[pawelrutkaq]

Hello @qor-lb @antonkri @FScholPer . Here is a release example in orchestration https://github.com/eclipse-score/orchestrator/releases/tag/v0.0.2

If we are fine, all could use a simple template:

# New features

# Improvements

# Known limitations or bugs

[masc2023]

Please use this template and tailor it for this release, https://eclipse-score.github.io/process_description/main/folder_templates/modules/module_name/docs/release/release_note.html#

Minimum could be:
New Features
————

• Feature 1: Brief description of the new feature.
• Feature 2: Brief description of the new feature.
• Feature 3: Brief description of the new feature.

Improvements
————

• Improvement 1: Brief description of the improvement.
• Improvement 2: Brief description of the improvement.
• Improvement 3: Brief description of the improvement.

Known Issues

• Issue 1: Brief description of the known issue. Justification regarding safety impact.
• Issue 2: Brief description of the known issue. Justification regarding safety impact.
• Issue 3: Brief description of the known issue. Justification regarding safety impact.

[pawelrutkaq]

@masc2023 great!

[FScholPer]

Release finished https://github.com/eclipse-score/reference_integration/releases/tag/v0.5.0-alpha