S-CORE Fortnightly

[dcalavrezo-qorix]

This thread collects S-CORE Fortnightly — every two weeks: what happened in Eclipse S-CORE, in plain language for technical and non-technical readers.

Each issue is posted as a comment below, so subscribe to this discussion to get every new issue as a notification. Generated automatically from public eclipse-score activity; every item links to its source. Corrections and feedback welcome as replies.

[dcalavrezo-qorix]

S-CORE Fortnightly — 2026-08-24 to 2026-09-06

Eclipse S-CORE kept up a steady pace over the past two weeks: more than 20 module releases shipped, over 200 pull requests were merged across dozens of repositories, and community meetings zeroed in on final preparations for the upcoming S-CORE v0.9 release. The headline news is that v0.9 is likely to slip by about a week while the team finishes a handful of module updates and irons out a new integration workflow (DR8). Alongside the release push, several modules adopted a shared, unified code-coverage pipeline, and the community continued discussing how AI-generated code should be reviewed and used going forward. Overall momentum remains high, with steady contributions and no breaking surprises for downstream users.

Highlights

• S-CORE v0.9 release is imminent but likely to slip about a week. The Technical Lead Circle confirmed the release is "in progress" and will probably move by roughly a week while a few modules (logging, time, config management) get final updates and the new DR8 integration workflow is polished. (minutes)
• The lifecycle module shipped five releases (v0.4.0 through v0.6.1) in two weeks, adding features like a "wait for file ready" startup condition and fixing a hash-stability bug that could crash a core process manager. (v0.6.1 release)
• A shared code-coverage pipeline is spreading across modules. baselibs, logging, kyron, time, inc_security_crypto, and orchestrator all switched to a single LLVM-based way of measuring test coverage for both C++ and Rust code, replacing several separate, inconsistent tools. (example)
• A new documentation-tooling release (docs-as-code v8.1.1) closed a quality gap where broken or undeclared documentation links could pass checks silently; it also improved how test results are shown in verification reports. (release)
• The project is discussing how to responsibly use AI-generated code, with a Technical Lead proposal in progress and a licensing question raised with the Eclipse Foundation. (minutes)
• This very newsletter and its companion daily digest were discussed by the Technical Lead Circle, which is working with the Eclipse Foundation on how to run it automatically going forward. (discussion)

What this means for adopters

• Facts:
  • baselibs v0.2.12 contains a breaking API change to StaticDestructionGuard; code that relies on its previous return type needs a check. (release)
  • The Bazel module score_lifecycle_health was renamed to score_lifecycle; consumers pinned to the old name need to update. (bazel_registry PR)
  • docs-as-code dropped a deprecated build parameter (scan_code); anyone still using it needs to update their documentation build configuration. (PR)
• What to check on your side:
  • If you consume lifecycle, review the v0.6.x release notes — several fixes touch process startup and shutdown behavior. (release)
  • If your team maintains its own coverage tooling, the shared LLVM coverage pipeline adopted by several modules may be worth evaluating for consistency. (example)
  • Watch for the final S-CORE v0.9 release announcement and its updated timeline, since several modules are still being finalized for that release. (tracking issue)

Releases at a glance

Module	Version	Date	What changed	Link
baselibs	v0.2.12	2026-08-26	Breaking API change to a utility class's storage accessor	release
bazel_cpp_toolchains	v1.0.2	2026-08-26	Fixed QNX build link-ordering bug	release
score_cpp_policies	v0.1.0	2026-08-26	First release; centralized compiler lint infrastructure	release
lifecycle	v0.4.0 / v0.5.0	2026-08-27	Deployment config improvements	v0.5.0
score_cpp_policies	v0.1.1	2026-08-27	Added tests/CI and migration docs	release
bazel_platforms	v1.1.0	2026-08-30	Added support for a new toolchain SDK version (pre-release toolchain)	release
docs-as-code	v8.1.0	2026-08-30	New test-result annotations and verification report template	release
bazel_cpp_toolchains	v1.0.3	2026-08-31	Added SDK support	release
kyron	v0.1.4	2026-08-31	Version bump ahead of v0.9	release
lifecycle	v0.6.0	2026-08-31	Pre-release. Added a "wait for file ready" condition	release
score-crates	v0.0.12	2026-08-31	Fixed a build lockfile issue	release
docs-as-code	v8.1.1	2026-09-02	Fixed silently-broken documentation links	release
logging	v0.2.3	2026-09-02	Dynamic configuration, safety documents, shared coverage pipeline	release
score	v0.7.2	2026-09-02	Documentation fixes	release
config_management	v0.2.0	2026-09-03	Build tooling and dependency update	release
logging	v0.2.4	2026-09-03	Minor fixes, documentation cleanup	release
rules_imagefs	v0.1.0	2026-09-03	First release; disk-image creation for testing	release
time	v0.0.2	2026-09-03	Adds a new build platform, refactors CI	release
lifecycle	v0.6.1	2026-09-06	Pre-release. Removed an unmaintained dependency, fixed shutdown bugs	release

Community pulse

Over the two weeks, community meetings covered a broad range of topics: testing conventions, Rust safety-critical coding guidelines, a base-libraries release for the upcoming S-CORE version, the Technical Lead Circle's v0.9 release checklist, an architecture decision on file/path name collisions, safety-requirements work for the Time feature, and a Persistency feature team working through its backlog. Roughly 15 community meetings posted minutes in this window, more than 200 pull requests were merged, over 20 module releases shipped, and several hundred issues were opened and closed (much of the closures tied to historical process-template cleanup). No meetings or discussions took place during a quiet 2026-08-28 to 2026-08-29 weekend.

Watch list

• S-CORE v0.9 release — tracked via the integration checklist; expected to slip by about a week while remaining modules (logging, time, config management) are finalized.
• The new DR8 integration workflow — still needs polishing before it replaces the current release process. (reference_integration PR)
• Guidance on using AI-generated code — a proposal is being prepared for the Technical Leads. (minutes)
• Automating this newsletter/daily digest in CI — the Eclipse Foundation is being consulted on running it as an official automated process. (discussion)

Glossary

• Bazel: the build tool used across S-CORE repositories to compile and test code consistently.
• Module: a self-contained S-CORE software component (e.g. lifecycle, logging, time) with its own versioned releases.
• ASIL: Automotive Safety Integrity Level, a risk classification used in automotive functional-safety standards.
• QNX: a real-time operating system commonly used in automotive and embedded systems, one of S-CORE's target platforms.
• Pre-release: a version explicitly marked as not yet safe or complete for production use.
• DR8 / integration workflow: the process used to combine module releases into an overall S-CORE release.

Footer

S-CORE Fortnightly is generated automatically from the S-CORE Daily issues of this period; those in turn come from public eclipse-score activity. Links go to the sources; corrections welcome as replies.

[dcalavrezo-qorix]

S-CORE Fortnightly — 2026-09-07 to 2026-09-20

The two weeks in one paragraph

Eclipse S-CORE kept up a steady release cadence over the past two weeks, publishing eight module releases — including the headline reference_integration v0.9.0 milestone and the first releases of a dedicated code-coverage tool — while merging roughly 220 pull requests across the organization. The most consequential structural change was splitting the code-coverage pipeline out into its own independently qualified module, a step toward formal tool certification. Two releases (baselibs and lifecycle) shipped with breaking changes that adopters should review before upgrading. Overall momentum remains strong: community meetings are shifting focus from the v0.9 milestone toward more frequent, lower-ceremony integration and toward v0.10/v1.0 planning.

Highlights

• reference_integration v0.9.0 shipped, the reference stack tying S-CORE modules together, bundling toolchain updates, a logging demo app, and documentation improvements. Release notes
• The code-coverage pipeline became its own module, score_coverage, split out of the general tooling repository so it can go through formal tool qualification; baselibs was the first module to migrate, with others following. Decision · first release
• A follow-up fix release, coverage_tool v0.2.0, corrected coverage reports that had been polluted by third-party code and contained broken links. Release notes
• baselibs v0.2.13 and lifecycle v0.7.0 both shipped with breaking changes on the same day: baselibs finished removing a deprecated date/time helper and some unused OS libraries, while lifecycle switched all configuration timing values from seconds to milliseconds. baselibs v0.2.13 · lifecycle v0.7.0
• The Release Community set a new expectation: every module should integrate into reference_integration at least once every two weeks, and module owners are asked to start producing a software bill of materials (SBOM), a machine-readable list of a component's software ingredients. Minutes
• A first release of the os_images and tooling repositories also landed: os_images v0.0.0 (an early pre-release baseline for OS image builds) and tooling v2.2.2 (parser and documentation fixes). os_images v0.0.0 · tooling v2.2.2

What this means for adopters

• Facts: baselibs v0.2.13 removes a deprecated date/time helper and several unused OS libraries. Release notes
• Facts: lifecycle v0.7.0 switches configuration timing fields from seconds to milliseconds, and a separate change rewrote its control interface on top of the mw::com communication middleware. Release notes · control API change
• Facts: score_coverage is now the recommended coverage pipeline; modules are migrating one by one, starting with baselibs. Tracking issue
• What to check: if you depend on baselibs or lifecycle, review the release notes before upgrading — both need code changes, not just a version bump.
• What to check: module maintainers should note the new two-week integration cadence and the SBOM request from the Release Community. Minutes
• What to check: the security/crypto module has a large review backlog, so expect slower turnaround if you depend on it. Minutes

Releases at a glance

Module	Version	Date	What changed	Link
reference_integration	v0.9.0	2026-09-07	Toolchain updates, logging demo app, documentation improvements	release
os_images	v0.0.0 (pre-release)	2026-09-10	First tagged release; license/layout setup, new OS image support	release
coverage_tool	v0.1.0 (first release)	2026-09-13	Bootstraps the new code-coverage pipeline module	release
docs-as-code	v8.1.2	2026-09-13	Documentation pages now use the full screen width	release
tooling	v2.2.2	2026-09-14	Parser and documentation improvements for diagram tooling	release
coverage_tool	v0.2.0	2026-09-16	Fixes coverage reports polluted by third-party code and broken links	release
baselibs	v0.2.13 — breaking	2026-09-17	Removes a deprecated date/time helper and unused OS libraries	release
lifecycle	v0.7.0 — breaking	2026-09-17	Configuration timing values switch from seconds to milliseconds	release

Community pulse

Community meetings met roughly two dozen times across recurring groups, including Infrastructure, Technical Lead Circle, Architecture, Release Community, Security & Crypto, Testing, Base Libs, Persistency, Time, Logging, Communication, and the SW Dev Process / Safety Team. Discussion shifted from wrapping up the v0.9 release (release notes, lessons learned, patch alignment) toward process changes: the coverage-tool split, a proposal to adopt Rust Edition 2024, a Rust-certification gap analysis for ISO 26262 compliance, and the new two-week integration cadence. Roughly 220 pull requests were merged and about 130 issues opened across the organization in this window, alongside the eight releases listed above.

Watch list

• v0.9 lessons-learned session, planned for the week of 22 September, expected to capture process improvements for release notes and documentation. Minutes
• Rust Edition 2024 upgrade proposal, pending formal adoption as a platform requirement. score#1499
• Rust certification gap analysis, a plan being reviewed by the Rust, tooling, and safety-manager communities for meeting ISO 26262 confirmation-review requirements. Discussion
• Continued rollout of score_coverage to more modules beyond baselibs. Tracking issue
• QNX private-storage request to the Eclipse Foundation, still pending. Discussion

Glossary

• Bazel: the build system S-CORE uses to compile code and manage dependencies across modules.
• Module: an independently versioned S-CORE component (e.g. baselibs, lifecycle, communication).
• Release candidate: a near-final build of a module offered for testing before an official release.
• ASIL: Automotive Safety Integrity Level, a risk classification used in automotive functional-safety standards (ISO 26262).
• SBOM: Software Bill of Materials, a structured list of the software components that make up a module.
• Tool qualification/confidence level: a formal process for showing that a development tool (like a coverage or build tool) can be trusted for use in a safety-relevant project.
• QNX: a real-time operating system used in some automotive and embedded contexts that S-CORE supports as a target platform.
• SOME/IP: a communication protocol used in automotive networks for exchanging service-oriented messages between electronic control units.

Footer

S-CORE Fortnightly is generated automatically from the S-CORE Daily issues of this period; those in turn come from public eclipse-score activity. Links go to the sources; corrections welcome as replies.

[dcalavrezo-qorix]

S-CORE Fortnightly — 2026-09-21 to 2026-10-04

The two weeks in one paragraph

Over these two weeks the Eclipse S-CORE community merged roughly 260 changes and published twelve releases, most of them in the supporting tools used to build, document and measure the quality of S-CORE modules. A major theme was making test coverage and verification evidence more complete, including coverage measurement on QNX (a commercial real-time operating system used in vehicles). The communication module reached version 0.5.0, though it is explicitly not for production use yet. One release removed deprecated build aliases and is flagged as a breaking change, which sparked a community discussion on how modules should adapt to deprecations. Overall momentum was steady, with a lot of cleanup and preparation work ahead of the 0.10 and 1.0 milestones.

Highlights

• Communication module v0.5.0. The module that lets software components exchange data published a new version with type-erased (more generic) bindings; the release notes say it has no safety argumentation or completed safety assessment yet and is not for production use. Release
• Coverage measurement on QNX. The coverage tool can now report how much code is exercised by tests running on QNX, and a follow-up fixed a case where coverage was heavily under-reported (13% shown instead of 80% for one library). v0.3.0, v0.3.1
• Breaking cleanup in the base libraries. Version 0.2.14 removed deprecated build aliases and helper shims, so consumers must switch to the replacements. Release
• Better traceability in documentation tooling. The documentation toolchain gained new verification-report templates and the ability to link a requirement to the build targets that implement it. v8.2.0, v8.3.0
• Infrastructure decision on QNX packages. The Infrastructure Community agreed to host the QNX development package itself, for S-CORE members and automated builds only, after download failures affected around half of CI jobs. Minutes
• Incubator repositories get rules. The Architecture Community decided that an early-stage proposal can get an incubator repository once an author finds a shepherd, and that it is archived or renamed when the proposal concludes. Minutes

What this means for adopters

Facts

• The baselibs 0.2.14 release is marked breaking; the Release Community noted several modules needed patches because they had not moved off deprecated APIs. Release, Minutes
• The CI cache action setup-bazel-cache v0.1.0 replaced all previous inputs. Release
• Security & Crypto plans to add crypto features in 1.0, integrated step by step into the reference integration during 0.10. Minutes
• The Technical Lead Circle discussed AutoSD as a platform option; it noted AutoSD is QM-only, so no safety manual exists. Minutes

What to check on your side

• If you use baselibs or the Bazel cache action, review the migration notes and update your build configuration.
• If you rely on QNX in CI, follow the planned SDP hosting and the Ubuntu 26 migration (beginning October 19, 2026). Minutes
• Treat communication 0.5.0 as non-production.

Releases at a glance

Module	Version	Date	What changed	Link
devcontainer	v1.11.1	2026-09-21	Bug-fix: tool version bumps, simpler run-tool script	link
cicd-actions (setup-bazel-cache)	v0.1.0	2026-09-22	Breaking: new inputs; independent cache save/restore	link
docs-as-code	v8.2.0	2026-09-22	Verification-report templates, module maturity attribute	link
coverage_tool	v0.3.0	2026-09-28	Coverage reporting for QNX targets	link
docs-as-code	v8.3.0	2026-09-28	Requirements linked to implementing build targets	link
baselibs	v0.2.14	2026-09-29	Breaking: deprecated aliases and shims removed	link
bazel_cpp_toolchains	v1.0.4	2026-09-29	Toolchain refactoring, AutoSD path fix	link
coverage_tool	v0.3.1	2026-09-29	Fixes QNX coverage under-counting	link
tooling	v2.2.3	2026-09-29	Diagram and C++ parser improvements, fixes	link
communication	v0.5.0	2026-10-01	Type-erased bindings; not for production use	link
tooling	v2.3.0	2026-10-01	Parser groundwork, reworked safety-analysis rules	link
bazel_cpp_toolchains	v1.0.5-rc1	2026-10-04	Pre-release: GCC flag derived from toolchain version	link

Community pulse

Meetings were recorded for the Architecture, Infrastructure, Release, Testing and SW Dev Process communities, the Technical Lead Circle, and the Base Libs, Security & Crypto, Time and Persistency feature teams (plus a weekly Rust sync), roughly 20 sets of minutes in the eight daily issues covering the period. Some days were combined, so counts are approximate.

Notable items:

• The Architecture Community agreed to use the Feature Enhancement Proposal (FEP) process also for non-functional changes such as design records. Minutes
• Open question: how to show in verification reports that a requirement is fully verified by several tests. Discussion
• Open question: what exactly counts as a "component". Discussion
• The Time team noted it lacks a systematic integration-level testing strategy. Minutes
• QNX job stability was described as very poor, with a conversation with QNX ongoing. Minutes

Activity: about 260 merged changes across the eight daily issues (typically 18–45 per issue), twelve releases, and well over 100 issues opened.

Watch list

• Final Comment Period votes on the pending FEP; votes were still missing. Minutes
• Release candidate v1.0.5-rc1 of the C++ toolchains. Release
• Whether modules adopt stricter deprecation warnings. Minutes
• Security & Crypto question on moving OpenSSL into a separate repository. Minutes
• A Safety Relevance Assertion Capability pilot proposal. Proposal

Glossary

• AutoSD: an automotive Linux-based platform option discussed as a target for S-CORE.
• Bazel: the build system S-CORE uses.
• CI: continuous integration, automated builds and tests.
• Deprecated: marked as scheduled for removal.
• FEP: Feature Enhancement Proposal, S-CORE's process for proposing changes.
• Module: a separately released S-CORE building block.
• QM / ASIL: quality-managed (no safety claim) versus automotive safety integrity levels.
• QNX: a commercial real-time operating system.
• Release candidate / pre-release: a trial version, not for production.
• SDP: QNX Software Development Platform.

S-CORE Fortnightly is generated automatically from the S-CORE Daily issues of this period; those in turn come from public eclipse-score activity. Links go to the sources; corrections welcome as replies.

[dcalavrezo-qorix]

S-CORE Fortnightly — 2026-10-05 to 2026-10-18

The two weeks in one paragraph

Over these two weeks S-CORE shipped around a dozen releases, including two shared building blocks that come with breaking changes, and the first release of a new module for AI-assistant tooling. A first module for building against the QNX software platform also appeared. Day-to-day work centred on safety documentation, code-quality clean-ups and making test and coverage reporting more complete, with well over 300 changes merged. Community meetings kept a steady rhythm, with preparation for an audit in early November and discussions about the v1.0 release visible in the minutes.

Highlights

• Two shared components shipped breaking changes. The base C++ libraries (v0.2.15) now use a single JSON parser, and the shared tooling (v3.0.0) reorganised how safety analyses are described. Both releases tell users to review the notes before upgrading. (baselibs, tooling)
• First QNX SDP module published. A new pre-release module hosts build targets for manually building the QNX software development platform and was added to the Bazel registry. (release)
• First release of mcp-servers. It provides the scaffold and data schema for an "Agent Context Attention Layer", tooling that gives AI assistants focused project context. (release)
• Documentation tooling and process description updated. docs-as-code v8.4.0 and process_description v2.2.0 were released, the latter adding workpackages to tool requirements. (docs-as-code, process description)
• Coverage reporting improved. Coverage tool releases v0.4.0 and v0.4.1 evaluate coverage per platform and fix empty reports; the base libraries already use it for coverage measured on QNX hardware. (v0.4.0, v0.4.1)
• Release workflow (DR8) moves forward. The Release Community decided to keep the dashboards split and agreed that test tooling should not leak into users' dependencies; module owners are to fix failing checks. (minutes 6 Oct, minutes 13 Oct)

What this means for adopters

Facts

• The base libraries removed the older JSON parser, and the old build flag for choosing a parser no longer does anything. The release is marked as not intended for production use, since no safety assessment is complete. (release)
• Tooling v3.0.0 renames attributes in the safety-analysis rules. docs-as-code v8.4.0 renames a root-cause attribute in its safety analysis types. (tooling, docs-as-code)
• A devcontainer release (1.11.1) was replaced by 1.11.2 after a checksum mismatch. (release)
• The score release v0.7.3 was reported as deleted and removed from the Bazel registry. (release)

What to check on your side

• If you build on the base libraries or tooling, read the release notes and remove or adapt affected build settings and safety-analysis definitions before upgrading.
• If you pinned devcontainer 1.11.1 or score 0.7.3, confirm you moved to an available version.
• Watch the request for C and Classic AUTOSAR support in the communication layer; today only C++ and Rust are officially supported. (discussion)

Releases at a glance

Module	Version	Date	What changed, in plain words	Link
tooling	v2.3.1	5 Oct	New version of shared tooling	release
score-crates	v0.0.13	6 Oct	Fixes lockfile generation after 0.0.12 was reported unusable	release
qnx_sdp	v0.0.1 (pre-release)	7 Oct	First module for building the QNX SDP	release
score	v0.7.3	7 Oct	New requirements and documentation fixes; later reported as deleted	release
itf	v0.6.0	8 Oct	Better virtual-machine support and core-dump extraction in the integration test framework	release
coverage_tool	v0.4.0	12 Oct	Coverage evaluated per platform; added tests	release
coverage_tool	v0.4.1	13 Oct	Fixes empty reports when measuring system headers	release
devcontainer	v1.11.1 / v1.11.2	13 Oct	Updated tools; 1.11.2 re-released after a checksum mismatch	v1.11.1, v1.11.2
docs-as-code	v8.4.0	13 Oct	Metamodel updates; compatibility change in safety analysis types	release
baselibs	v0.2.15	14 Oct	Single JSON parser (breaking)	release
tooling	v3.0.0	14 Oct	Safety-analysis rules reorganised (breaking)	release
mcp-servers	v0.1.0	15 Oct	First release, scaffold and schema	release
process_description	v2.2.0	16–18 Oct	Workpackages added to tool requirements	release

Community pulse

• Activity: about 14 releases and roughly 340 or more merged changes across the dailies that stated a count, plus a large backlog clean-up of 78 issues closed on 5 October. Roughly 25 community meeting notes were posted.
• Teams that met: Architecture, Infrastructure, Technical Lead Circle, Release, Software Development Process (including its Safety team), Testing, and feature teams for Base Libs, Persistency, Security & Crypto, Time, Lifecycle, Logging and Communication.
• Decisions: the Time team recorded that its callback implementation is merged and that the merge queue is beneficial (minutes); the Release Community chose to keep dashboards split (minutes).
• Open questions: whether the 2026 progress review and the v1.0 release review should be combined (minutes); which modules are "safe" for v1.0 (minutes).

Watch list

• Audit preparation: sessions are planned for 4–6 November. (minutes)
• Downloadable images for S-CORE v1.0; the notes say QNX "probably will not allow" a public one. (minutes)
• A draft decision record proposing DDS communication support beneath the communication layer. (pull request)
• Module owners fixing failing DR8 workflow checks. (minutes)
• Presenting the AI concept in the audit. (minutes)

Glossary

• Bazel: the build system used by S-CORE; its registry lists available modules.
• Module: a separately released building block of S-CORE.
• Pre-release: an early version not yet meant for general use.
• Breaking change: a change that may require users to adapt their setup.
• ASIL: automotive safety integrity level, a rating of safety requirements.
• SBOM: software bill of materials, a list of the software inside a product.
• QNX: a commercial real-time operating system.
• DR8: a release verification workflow discussed in the Release Community.
• ITF: the integration test framework.

S-CORE Fortnightly is generated automatically from the S-CORE Daily issues of this period; those in turn come from public eclipse-score activity. Links go to the sources; corrections welcome as replies.