R-TF-012-030 Software Configuration Management Plan

Object

This document is an integral part of the Technical File (TF) for the medical device (MD).

The purpose of this document is to establish and maintain the software configuration management plan the medical device software.

Scope

This document only applies to medical device.

This plan should be reviewed, updated and approved according to changes of design and of development.

Abbreviations, Terms & Definitions

Abbreviation / Term	Definition
Git	A distributed version control system used to track changes in source code during software development
Git branch	A lightweight movable pointer to a commit in a repository's history
Git cherry-pick	Git command to apply a specific commit from one branch to another, selectively incorporating changes without merging entire branches
Git commit	A snapshot of the repository at a particular point in time
Git commit SHA1	A 40-character string that uniquely identifies a specific commit in a Git repository
Git commit short SHA1	A truncated version of the full SHA1 hash (typically first 7–10 characters)
Git tag	A reference that points to a specific commit in a repository's history
Github Repository	Provides Git hosting infrastructure in the cloud
Github Actions	Continuous integration and continuous deployment (CI/CD) platform to automate software workflows
Repository issues	A feature in GitHub that allows users to track bugs, enhancements, and other requests related to a project
Continuous Integration (CI)	Development practice where code changes are frequently integrated and automatically verified by builds and tests
Pull Request (PR)	A version control feature to notify team members that a set of changes is ready for review and potential merge into another branch

Organization

The company uses Git as version control software. The Git provider is GitHub, which in addition to hosting repositories provides Pull Request workflows, built-in Continuous Integration via GitHub Actions, and integration with the issue tracking system available in GitHub. Every file required to build and deploy the API is committed to version control. The software configuration is managed by members of the project. Responsibilities are shared between the software engineers.

Configuration Management Principles

The software engineer may use the Git command line. The main branch contains the latest reviewed and merged code.

Branch types:

• Feature: feat/<issue-number>-<slug>
• Bug fix: fix/<issue-number>-<slug>
• Maintenance/chore: chore/<issue-number>-<slug>
• Release: release/MAJOR.MINOR

All changes are merged into main (or release/MAJOR.MINOR when applicable) via Pull Request.

Each branch and PR must reference a GitHub Issue (e.g., #1234). PR titles follow Conventional Commits (e.g., "feat: add user invites (#1234)").

Releases follow Semantic Versioning and are tagged vMAJOR.MINOR.PATCH.

Feature branches

• May branch off from: main
• Must be merged back into: main using squash merge
• Branch naming convention: feat/<issue-number>-<short-description>

When a new feature is requested, the software engineerzº (author) creates a feature branch from main. The author may create intermediate commits, pushes all modifications, and then opens a Pull Request. The Pull Request must reference the related GitHub Issue (e.g., #1234) and follow Conventional Commits in its title.

Release branches

• May branch off from: main
• Branch naming convention: release/MAJOR.MINOR

When main reflects the desired state for a new release, a release candidate tag vMAJOR.MINOR.0-rc1 is created.

The desired state is met when:

• All features targeted for the release are merged into main.
• There are no unresolved critical or major bugs.
• Minor bugs may remain if they do not affect safety, core functionality, or intended usage of the system.

Final releases are tagged using Semantic Versioning (vMAJOR.MINOR.PATCH).

Merge feature policy

When preparing a release (e.g., vX.Y.0), the main branch is frozen for stabilization. Only release-critical bug fixes are allowed to merge into main until the release candidate (vX.Y.0-rc1) is tagged and verified.

Features that target a future release (e.g., vX.(Y+1).0) must not be merged into main while the current release is being stabilized. They remain in their feature branches until the stabilization window ends.

Options during this period:

• Keep the feature branch open until the release candidate is finalized, or
• Merge it behind a disabled feature flag so it cannot affect the release under test.

If a future feature is the only planned change for the next release, once it is merged into main and verified, main may be directly tagged as the new release (e.g., vX.(Y+1).0).

Fix a bug in a release candidate

When a bug fix is needed on a first release candidate vMAJOR.MINOR.0-rc1, create (or use) release/MAJOR.MINOR branched from the commit on main tagged vMAJOR.MINOR.0-rc1.

• If the bug is also present on main, integrate the fix on main first, then backport it to release/MAJOR.MINOR via cherry-pick.
• If the bug is not present on main, fix it directly on release/MAJOR.MINOR.

After the last required fix is integrated on release/MAJOR.MINOR, tag:

• vMAJOR.MINOR.0-rc2 if minor, non-blocking issues remain that do not affect safety, core functionality, or intended use.
• vMAJOR.MINOR.0 when all critical, major, and minor issues are resolved or explicitly accepted with no user-impacting risk.

All changes are delivered through Pull Requests with passing checks and required reviews.

Fix a bug in a release

There are two situations:

info

• All changes flow via Pull Requests with required reviews and passing checks.
• If a bug affects main, always fix main and then backport (cherry-pick) to the relevant release/MAJOR.MINOR.
• Releases and candidates use Semantic Versioning tags: vMAJOR.MINOR.PATCH and vMAJOR.MINOR.PATCH-rcN.

No release branch (release was tagged on main)

When a bug fix is needed on vMAJOR.MINOR.0 or vMAJOR.MINOR.0-rc1:

• Create release/MAJOR.MINOR from the corresponding tag on main.
• If the bug also exists on main, fix it on main first, then cherry-pick to release/MAJOR.MINOR.
• If the bug is not present on main, fix it directly on release/MAJOR.MINOR.

After integrating all required fixes on release/MAJOR.MINOR:

• Tag vMAJOR.MINOR.1-rc1.
• If no additional bugs are found, tag vMAJOR.MINOR.1.
• If issues remain, iterate with -rc2, -rc3, … until ready, then tag vMAJOR.MINOR.1.

Release branch already exists

When a bug fix targets an existing maintenance line:

• Add the fix to release/MAJOR.MINOR.
• Tag vMAJOR.MINOR.(PATCH+1)-rc1.
• If further issues are found, continue with vMAJOR.MINOR.(PATCH+1)-rc2, -rc3, …
• When verified, tag vMAJOR.MINOR.(PATCH+1).

Release build

A release build of the device is generated:

• either from a release candidate tag MAJOR.MINOR.PATCH-rc<n>,
• either from a release tag MAJOR.MINOR.PATCH.

Bug branches

Branch naming

• From main: fix/<issue-number>-<slug>, e.g., fix/2431-null-pointer-on-login
• From a release line: fix/<issue-number>-release-X.Y, e.g., fix/2431-release-1.8

General rules

• Every bug fix has a GitHub Issue; PRs must reference it (e.g., Closes #2431).
• PR titles follow Conventional Commits (e.g., fix: guard null session (#2431)).
• CI must pass; at least one review required.
• If a release branch exists for the affected line, ship the fix there too via cherry-pick.
• Ensure backward compatibility with the release build and add/extend tests.

Case A — The bug is present on main

1. Create branch from main: fix/issue-number-slug
2. Implement fix: Add tests that would fail pre-fix.
3. Merge to main via PR: squash merge preferred; keep the issue reference.
4. Backport to release (if release/MAJOR.MINOR exists)
   • Create branch from release/MAJOR.MINOR: fix/issue-number-slug-release-MAJOR.MINOR
   • Cherry-pick the main fix commit(s).
   • Open PR into release/MAJOR.MINOR.
5. Tag on the release branch
   • First candidate: vMAJOR.MINOR.(PATCH+1)-rc1
   • Iterate -rc2, -rc3, … as needed, then tag vMAJOR.MINOR.(PATCH+1).

Case B — The bug is NOT present on main (release-only)

1. Create branch from release/MAJOR.MINOR: fix/<issue-number>-release-MAJOR.MINOR
2. Implement fix. Add tests validating the release behavior.
3. Merge to release/MAJOR.MINOR via PR
4. Tag on the release branch
   • vMAJOR.MINOR.(PATCH+1)-rc1 → iterate as needed → vMAJOR.MINOR.(PATCH+1).
5. Optional guard on main. If useful, add a regression test or defensive code to main to prevent reintroduction.

Notes

• Prefer cherry-pick over merging main into a release branch to avoid dragging unrelated changes.
• If multiple releases are supported, repeat the cherry-pick into each active release/X.Y line, tagging candidates per line.
• Keep fixes minimal and isolated; large refactors don’t belong in a patch release.

Configuration Management in a Development Cycle

Pull Request Workflow

All feature or bug-related modifications submitted in the Git repository follow a PR workflow. The workflow validates the modifications made in a branch versus its originated branch before integration.

The workflow is the following:

• The software engineer, author of the branch, creates the PR.
• Continuous Integration (CI) runs predefined actions such as all automated tests.
  • If any action fails, the software engineer is notified.
• The author assigns one or more reviewers to the PR.
• The reviewers review the pull request:
  • They may approve it.
  • They may request changes.
  • They may add comments or ask questions into the PR.
• The author replies to all comments and questions and marks them as resolved.
• If the originated branch has changed since the PR branch was created, the author must rebase the feature or bug branch with the originated branch before merging.
  • An originated branch is either main or a release/MAJOR.MINOR branch.
• When all reviewers have approved, all comments/questions are resolved, and CI checks pass, the author squash-merges the branch into its originated branch.

The PR is then merged into its originated branch, which is either main or a release/MAJOR.MINOR branch.

Release deployment

Deployments of a release tag to the production environment are managed by a software engineer who follows a defined procedure. Refer to the Software Development Plan.

Releases Configuration Management

Releases are managed with tags and release branches as described in section 6.1 Configuration management principles. All tags follow Semantic Versioning (SemVer 2.0):

• vMAJOR.MINOR.PATCH for a stable release
• vMAJOR.MINOR.PATCH-rc<n> for a release candidate, where <n> is the candidate index

See section 7.1 of this document for details on version increments.

Tasks in Development and Maintenance

The tasks depend on the phase of the Software Development or Maintenance Project. Software Configuration Management performs the following operations during the software life cycle.

Event	Operations
Start the development of a new project	Create the directory structure in the main branch.
Create a new major or minor version	Tag the commit on main as vMAJOR.MINOR.0-rc1.
Release a new patch version of MAJOR.MINOR on main	If main does not contain features targeting a future release, tag the commit on main as vMAJOR.MINOR.PATCH. Generate the version. Archive the version. Deploy the version in the production environment.
Release a new patch version of MAJOR.MINOR on release/MAJOR.MINOR branch	Tag the commit on release/MAJOR.MINOR as vMAJOR.MINOR.PATCH. Generate the version. Archive the version. Deploy the version in the production environment.

The software development team updates the source code of the branch as needed.

Modification type	Modification localisation
Create a new feature in the next major or minor version	See Configuration management principles > Feature branches section.
Change an existing feature in the next major or minor version	Same as Create a new feature in the next major or minor version.
Fix a bug in a released version	See Configuration management principles > Bug branches section.
Fix a bug during the verification phase	Same as Fix a bug in a released version.

Link Between Source Control and Bugs/Features

To enable the link between GitHub Issues and commits, each commit message and Pull Request must reference the related issue. This ensures traceability between reported bugs/features and the corresponding code changes.

• Commits should include the GitHub issue number in the message.

  • Example: fix: handle null session (#1234)
  • GitHub automatically links #1234 to the referenced issue.

• Branches should include the issue number in their name. Examples:

  • feat/1234-user-invites
  • fix/987-release-1.8-login-bug

• Pull Requests must reference the issue in their description or title.

  • Example: feat: add user invites (#1234)
  • This allows GitHub to close the issue automatically when the PR is merged.

Configuration Identification

Configuration items identification rules

The identification of configuration items follows the scheme: <configuration-item-name>_<MAJOR>.<MINOR>.<PATCH>[-<PreReleaseTag>]+<BuildMetadata>

• MAJOR, MINOR, PATCH: Standard version numbers following Semantic Versioning (SemVer).
• PreReleaseTag: Optional. If present, indicates a pre-release (e.g., rc1, rc2 for release candidates).
• BuildMetadata: Composed of the letter g followed by the Git commit short SHA1.

Examples:

• Stable release: md-1.1.0+g1511f32b
• Release candidate: md-1.1.0-rc2+g1511f32b

This naming scheme ensures that:

• Multiple items can be generated for the same version (MAJOR.MINOR.PATCH) from different commits.
• Every release, including intermediate ones (end of a sprint, validation build, or Pull Request candidate), is reproducible and uniquely traceable to source code.

The version number starts at 1.0.0.

Version increments

• MAJOR: Incremented when substantial modifications are made to the medical device, such as:

  • Updating the intended use.
  • Changing the significance of information provided.
  • Changing the intended disease, condition, or expanding the patient population.
  • Introducing or altering risks that require new control measures.
  • Significant changes in the algorithm (e.g., AI/ML architecture).
  • Adding new diagnostic or therapeutic features.
  • Expanding compatibility with new input sources or data types.
  • Major cloud architecture changes.
  • Major updates of the GUI or reporting interfaces that affect medical data presentation.

• MINOR: Incremented when non-substantial modifications are made, such as:

  • Adding new modules that do not affect medical decision-making.
  • Extending existing modules with non-critical functionalities.
  • Algorithm updates using the same methods for development and validation, resulting in improved performance.
  • Retraining with new datasets of the same type.
  • Non-substantial preprocessing changes.
  • Technology modifications without medical impact.
  • Minor UI/UX updates that improve clarity.

• PATCH: Incremented when bugs are fixed in the existing functionalities of MAJOR.MINOR.

SOUP identification rules

The identification of SOUPs (Software of Unknown Provenance) follows the scheme: <SOUP-package-name>_<MAJOR>.<MINOR>.<PATCH>

• SOUP package name: The name of the open-source project or the vendor + library/software name.
• MAJOR, MINOR, PATCH: Standard version numbers provided by the supplier.
  • Note: sometimes the patch number is not numeric.

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003, JD-004
• Approver: JD-001