View on GitHub

Lightspeed core service

Lightspeed core service

Supporting backport changes for releases

   
Date 2026-03-30
Component lightspeed-stack
Authors Pavel Tišnovský
Feature / Initiative LCORE-1349
Spike LCORE-1596
Links Spike doc: docs/design/supporting-backport-changes-for-releases/

What

Supporting backport changes for releases means having processes and technical support to take bug fixes, security patches, or small feature adjustments made in the current (or main) codebase and apply them to older released versions so those releases can be updated without merging forward-only development. Concretely this includes:

In short: ensure you can reliably and safely apply, test, review, document, and release fixes to past released versions without disrupting mainline development.

Why

We need the ability to create and maintain separate branches of the Lightspeed Core Stack (LCS) codebase after each formal release so that, if any Lightspeed team requests an urgent or on-demand patch, we can apply fixes to the released version without disrupting ongoing development on the mainline. This branching workflow should include versioned branch names, clear merge/backport/cherrypick procedures, automated testing for patch branches, and a defined process for releasing and documenting any hotfixes.

Here are key advantages that will allow the LCORE team to support its customers:

Requirements

R1

Long-term support for specific LCORE releases with the ability to fix bugs and CVE in all supported versions. Provide a formal Long-Term Support (LTS) program for designated LCORE release versions that ensures ongoing maintenance, security, and stability for those supported releases.

R2

Supported-release policy. Defined support window: Publish explicit start and end dates for support of each LCORE release (e.g., 18–24 months), and document criteria for extending or ending support.

R3

Supported versions list: Maintain an authoritative list of currently supported LCORE releases and the type of support (security-only, critical-bug + security, full support).

R4

Timely fixes: Commit to SLAs for addressing defects and security vulnerabilities (e.g., triage within 24 hours, patch within X days depending on severity).

R5

CVE handling: Track, triage, and remediate CVEs affecting any supported release; coordinate CVE assignment, disclosure, and patch publication according to industry best practices.

R6

Release branches: Maintain long-lived release branches for each supported version to apply fixes without impacting mainline development.

R7

Backport process: Provide a documented, repeatable process to backport fixes (including code adaptation, conflict resolution, and compatibility verification).

Use Cases

U1

As a Lightspeed Core Stack developer I was notified about CVE in version x.y. I need to fix the CVE in that particular version without altering older (stable) versions.

U2

As a Lightspeed Core Stack developer I was notified about bug in version x.y. I need to fix the bug in that particular version w/o altering older (stable) versions.

U3

As a Lightspeed Core Stack developer I need to implement new feature planned in version x+1, but maintain compatibility in version x.

U4

As a Lightspeed Core Stack developer I have to change the API, but the older Lightspeed Core Stack versions should not be affected by this change.

U5

As a Lightspeed Core Stack developer I need to backport the CVE from main branch to given version x.y.

U6

As a Lightspeed Core Stack developer I need to backport the bug from main branch to given version x.y.

U7

As a Lightspeed Core Stack developer I need to backport the CVE from version X branch to version Y without altering other versions.

U8

As a Lightspeed Core Stack developer I need to backport the bug from version X branch to version Y without altering other versions.

U9

As Lightspeed Core Stack user I need to have a list of supported versions, support windows, status of versions etc. Similar to https://devguide.python.org/versions/

Solution

We will adopt a Git workflow that creates and maintains dedicated release branches for each published Lightspeed Core Stack version, and pair that with strict semantic versioning to clearly communicate the nature of each release.

Concretely:

This approach keeps ongoing development separate from maintenance work, ensures clear, predictable version numbers for consumers, and provides a repeatable process for issuing hotfixes and patch releases.

Release branch

A release branch is a Git branch used to prepare a new production release. It stabilizes the codebase for final testing, bug fixes, and release-specific tasks without blocking ongoing feature development on main/develop. Those branches will have the following naming schema:

release/MAJOR.MINOR.PATCH

Key points

Semantic versioning

Semantic Versioning (SemVer) is a versioning scheme that conveys meaning about changes in a release using a three-part number: MAJOR.MINOR.PATCH.

Rules (concise)

Benefits

Branches naming

Branch Description
main production-ready code
release/x.y.z release stabilization branch
feature/* new features
hotfix/* urgent production fixes

NOTE: the actual proposal covers just release branches, not feature nor hotfix ones.

Release branches visualization

One release branch

|  * tag: v0.6.0
|  * release/0.6.0  (release branch)
|  * commit C6
|  * commit C5
*  | commit C4
*  | commit C3
| /
|/
* commit C2
* commit C1  (main)

Two release branches

|  *  tag: v2.0.0
|  *  release/2.0
|  *  commit R2-2
|  *  commit R2-1
|  | 
|  |  * tag: v1.2.1
|  |  * release/1.2
|  |  * commit R1-3
|  |  * commit R1-2
|  |  * commit R1-1
|  | /
|  |/
|  * commit C6
*  | commit C5
*  | commit C4
| /
|/
* commit C3
* commit C2
* commit C1  (main)

Proposed workflow

Steps (ordered)

  1. Create release branch

  2. Update metadata, such us version etc.

  3. Run CI: full test suite, linters, build (this is to check that branching is ok)

  4. Stabilize: apply bug fixes, adjust configurations, small polish commits on release branch

  5. QA / UAT: Deploy release branch to staging environment (Konflux)

  6. Fix issues: commit fixes directly on release branch; re-run CI

  7. Prepare release: Finalize changelog, update docs, set release notes

  8. Deploy: trigger production deployment (Konflux)

  9. Hotfixes (if needed): create hotfix/x.y.z+1 from main, then follow same flow

Visualized flow

                 +-----------------+
                 |   main branch   |
                 |                 |
                 +--------+--------+
                          | 
                          |  create release/x.y.z
                          v 
                 +-----------------+
                 |  release/x.y.z  |
                 |  (stabilize)    |
                 +----+---+---+----+
                      |   |   |
     update changelog |   |   | bug fixes & CI
                      |   |   |
                      v   v   v
                 +-----------------+
                 | Run CI / Tests  |
                 +--------+--------+
                          | 
                          v 
                 +-----------------+
                 |  Run e2e tests  |
                 |  in Konflux     |
                 |                 |
                 +--------+--------+
                          |
            issues found  |  validated
                 +--------+-----------+
                 |                    |
                 v                    v
       +----------------+     +----------------+
       | Fix on release |     | Ready for ship |
       +-------+--------+     +-------+--------+
               |                      |
               v                      v
          (re-run CI)          tag the release
               |                      |
               v                      v
       +----------------+     +----------------+
       |  return to QA  |     |    (tag vX)    |------------+
       +----------------+     +----------------+            |
                                      |                     |
                                      v                     v
                              +----------------+    +-----------------+
                              |  Build images  |    | Publish on PyPi |
                              +----------------+    +-----------------+

Cherry picking

Cherry-picking is a Git operation that applies the changes introduced by a specific commit from one branch onto another branch without merging the entire branch history. Key points:

NOTE: the cherry picking can be made in main -> release branch direction or vice versa. We prefer the first method when possible.

Git workflow

New release branch

# 1. Create release branch from the main branch
git checkout -b release/1.2.0 main

# 2. Update version number in build files

# 3. Commit and push
git commit -am "Prepare for 1.2.0 release"
git push origin release/1.2.0

# 4. Tag the release
git tag -a v1.2.0 -m "Release 1.2.0"
git push origin v1.2.0

# 5. Merge into main (optional step)
git checkout main && git merge release/1.2.0

Update/fix existing release branch

# 1. Create branch from the release branch
git checkout -b release/1.2.1 release/1.2.0

# 2. Update version number in build files

# 3. Commit and push
git commit -am "Prepare for 1.2.1 fix"
git push origin release/1.2.1

# 4. Tag the release
git tag -a v1.2.1 -m "Release 1.2.1"
git push origin v1.2.1

NOTE: 1.2.0 and 1.2.1 are just examples, of course.

Branching visualization on CLI

Using git-graph tool:

   ●                              59c674c (HEAD -> release/1.2.3) Fix for 1.2.3
   │   ●                          dbc9619 (lcore-1602-update-lcore-version, origin/lcore-1602-update-lcore-version) LCORE-1602: Update LCORE version
   │   │ ●                        5d14721 (origin/lcore-1562-fixed-link) Update docs/design/conversation-compaction/conversation-compaction.md
 ┌─┴───┘ ●                        ad639c1 LCORE-1562: Fixed lin in FA
 ○<────┬─┘                        1b68d36 (main, origin/main, upstream/main) Merge pull request #1434 from tisnik/lcore-1319-more-jira-projects
 │     ●                          1395ad8 (origin/lcore-1319-more-jira-projects) LCORE-1319: More JIRA projects
 ├─────┘                          
 ○<──────┐                        9c9410c Merge pull request #1432 from asimurka/clear_reasoning_and_max_out_tokens
 ○<──────┼─────┐                  6c2ae1e Merge pull request #1399 from max-svistunov/lcore-1576-feature-design-process
 │       │     ●                  66d3557 Update JIRA ticket template
 ○<────┐ │     │                  d206a03 Merge pull request #1433 from tisnik/lcore-1319-updated-pr-title-checker
 │     ● │     │                  36ca0e4 (origin/lcore-1319-updated-pr-title-checker) LCORE-1319: Updated PR title checker
 │     │ ●     │                  fb50736 Clear reasoning and max_output_tokens in responses
 ├─────┴─┘ ●   │                  3e6c633 (origin/test-xyzzy) Test XYZZY
 ├─────────┘   │                  
 ○<────┐       │                  ee0bcf9 Merge pull request #1429 from tisnik/lcore-1319-pr-title-checker
 │     ●       │                  d0c8c97 (origin/lcore-1319-pr-title-checker) PR title checker GH action
 │     ●       │                  feae91c PR title checker config
 ├─────┘       │

Epics created

Epic Description Link
LCORE-1619 Documentation containing long term support informations https://redhat.atlassian.net/browse/LCORE-1619
LCORE-1620 Up to date page with supported and unsupported LCS versions https://redhat.atlassian.net/browse/LCORE-1620
LCORE-1621 Implementation of official branching strategy https://redhat.atlassian.net/browse/LCORE-1621
LCORE-1622 Accommodation phase: make 0.5.0 release branch with all required attributes https://redhat.atlassian.net/browse/LCORE-1622
LCORE-1623 Production phase: make 0.6.0 release branch with all required attributes https://redhat.atlassian.net/browse/LCORE-1623

Stories created

| Epic | Story | Description | Link | |————|——-|—————–|—————–|

Unknowns

References

Changelog

TODO: Record significant changes after initial creation.

Date Change Reason
2026-03-30 Initial version feature request
2026-03-31 Created epics refinement