LCORE-1596: Spike document#1439
Conversation
WalkthroughNew design document added detailing an end-to-end process for backporting fixes into released Lightspeed Core Stack versions, covering scope, support policies, branching/versioning conventions, semantic versioning, stabilization workflow, CI/testing, cherry-picking, and release/hotfix procedures. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~15 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
PR Reviewer Guide 🔍Here are some key observations to aid the review process:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md`:
- Around line 583-587: The "Stories created" section currently has only the
table header; update the "Stories created" table under the "Stories created"
heading by either adding the missing story rows (populate Epic, Story,
Description, Link entries) or, if no stories exist yet, insert a clear
placeholder row or single-line note such as "To be created" or "Pending
refinement" so the table is not empty; edit the markdown table immediately
beneath the "Stories created" heading to include the placeholder or real
entries.
- Line 575: Update the table row containing "LCORE-1619" so the description
reads "Documentation containing long-term support information" instead of
"Documentation containing long term support informations": replace the plural
"informations" with the uncountable "information" and add the hyphen to
"long-term" for correct compound adjective formatting.
- Line 237: Replace the unhyphenated phrase "end to end tests" with the
correctly hyphenated compound adjective "end-to-end tests" wherever it appears
(e.g., the phrase in the sentence "including unit, integration, and end to end
tests") so the compound adjective properly modifies "tests".
- Around line 345-346: The NOTE line currently reads "NOTE: the actual proposal
covers just release branches, not feature nor hotfix ones." — update that phrase
to a clearer construction such as "not feature or hotfix ones" or "neither
feature nor hotfix ones" by replacing "not feature nor hotfix" with the chosen
wording in the NOTE sentence to improve grammar and clarity.
- Line 101: Replace the misspelled phrase "Lighspeed Core Stack" with the
correct "Lightspeed Core Stack" wherever it appears in the document
(specifically update the occurrence matching the exact text "Lighspeed Core
Stack"); ensure capitalization matches the rest of the doc and run a quick
search to confirm no other instances remain.
- Around line 272-274: The Markdown code blocks for the branch naming schema
(the block containing "release/MAJOR.MINOR.PATCH") and the ASCII visualizations
do not include language specifiers, causing poor rendering; update each of those
fenced code blocks (including the block with "release/MAJOR.MINOR.PATCH" and the
ASCII diagram blocks referenced in the comment) to use a language tag of "text"
(e.g., change ``` to ```text) so viewers render them correctly, and apply the
same change to the other identified code fences in the document.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 2a6c48cf-eea4-4b2b-b300-a6a96582b1c8
📒 Files selected for processing (1)
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: build-pr
- GitHub Check: Pylinter
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
- GitHub Check: E2E: server mode / ci
- GitHub Check: E2E Tests for Lightspeed Evaluation job
- GitHub Check: E2E: library mode / ci
🧰 Additional context used
🪛 LanguageTool
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
[grammar] ~101-~101: Ensure spelling is correct
Context: ...e and maintain separate branches of the Lighspeed Core Stack (LCS) codebase after each fo...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[style] ~185-~185: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to implement new feature planned in versio...
(REP_NEED_TO_VB)
[style] ~195-~195: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to backport the CVE from main branch to gi...
(REP_NEED_TO_VB)
[style] ~200-~200: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to backport the bug from main branch to gi...
(REP_NEED_TO_VB)
[style] ~205-~205: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to backport the CVE from version X branch ...
(REP_NEED_TO_VB)
[style] ~210-~210: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to backport the bug from version X branch ...
(REP_NEED_TO_VB)
[style] ~215-~215: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... ## U9 As Lightspeed Core Stack user I need to have a list of supported versions, supp...
(REP_NEED_TO_VB)
[grammar] ~237-~237: Use a hyphen to join words.
Context: ...ch, including unit, integration, and end to end tests, before being packaged. * S...
(QB_NEW_EN_HYPHEN)
[grammar] ~290-~290: Ensure spelling is correct
Context: .... * Typical tasks on the branch: final bugfixes, documentation, version bump, packagi...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[style] ~315-~315: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ty in a backwards-compatible manner. * Increment PATCH when you make backwards-compatibl...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[grammar] ~345-~345: Ensure spelling is correct
Context: ...vers just release branches, not feature nor hotfix ones. ## Release branches vis...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~473-~473: Use a hyphen to join words.
Context: ... +-----------------+ ``` ### Cherry picking Cherry-picking is a Git operati...
(QB_NEW_EN_HYPHEN)
[uncategorized] ~575-~575: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...| LCORE-1619 | Documentation containing long term support informations ...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[uncategorized] ~576-~576: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ....net/browse/LCORE-1619 | | LCORE-1620 | Up to date page with supported and unsupported LCS...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
🪛 markdownlint-cli2 (0.22.0)
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
[warning] 272-272: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 354-354: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 369-369: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 422-422: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 547-547: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (1)
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md (1)
502-537: LGTM: Git workflow examples are clear and correct.The bash examples for creating new release branches and updating existing ones are well-structured, properly commented, and demonstrate the workflow clearly. The commands are syntactically correct and follow Git best practices.
.../design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
Outdated
Show resolved
Hide resolved
.../design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
Outdated
Show resolved
Hide resolved
| ``` | ||
| release/MAJOR.MINOR.PATCH | ||
| ``` |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Add language specifier to code blocks.
The code blocks for branch naming schema (here) and ASCII visualizations (lines 354, 369, 422, 547) lack language specifiers, which prevents proper rendering in many Markdown viewers. Consider adding text as the language identifier.
📝 Proposed fix for this block
-```
+```text
release/MAJOR.MINOR.PATCH</details>
Apply similar changes to the other code blocks at lines 354, 369, 422, and 547.
<details>
<summary>🧰 Tools</summary>
<details>
<summary>🪛 markdownlint-cli2 (0.22.0)</summary>
[warning] 272-272: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
</details>
</details>
<details>
<summary>🤖 Prompt for AI Agents</summary>
Verify each finding against the current code and only fix it if needed.
In
@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
around lines 272 - 274, The Markdown code blocks for the branch naming schema
(the block containing "release/MAJOR.MINOR.PATCH") and the ASCII visualizations
do not include language specifiers, causing poor rendering; update each of those
fenced code blocks (including the block with "release/MAJOR.MINOR.PATCH" and the
ASCII diagram blocks referenced in the comment) to use a language tag of "text"
(e.g., change totext) so viewers render them correctly, and apply the
same change to the other identified code fences in the document.
</details>
<!-- fingerprinting:phantom:triton:puma:bee038db-27d3-4c67-846c-ad77f15841d1 -->
<!-- This is an auto-generated comment by CodeRabbit -->
| NOTE: the actual proposal covers just release branches, not feature nor hotfix | ||
| ones. |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Simplify conjunction for clarity.
The phrase "not feature nor hotfix" is grammatically awkward. Use "not feature or hotfix" instead, or "neither feature nor hotfix" if you prefer the neither-nor construction.
📝 Proposed fix
-NOTE: the actual proposal covers just release branches, not feature nor hotfix
+NOTE: the actual proposal covers just release branches, not feature or hotfix
ones.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| NOTE: the actual proposal covers just release branches, not feature nor hotfix | |
| ones. | |
| NOTE: the actual proposal covers just release branches, not feature or hotfix | |
| ones. |
🧰 Tools
🪛 LanguageTool
[grammar] ~345-~345: Ensure spelling is correct
Context: ...vers just release branches, not feature nor hotfix ones. ## Release branches vis...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md`
around lines 345 - 346, The NOTE line currently reads "NOTE: the actual proposal
covers just release branches, not feature nor hotfix ones." — update that phrase
to a clearer construction such as "not feature or hotfix ones" or "neither
feature nor hotfix ones" by replacing "not feature nor hotfix" with the chosen
wording in the NOTE sentence to improve grammar and clarity.
|
|
||
| | Epic | Description | Link | | ||
| |------------|-----------------------------------------------------------------------------|------------------------------------------------| | ||
| | LCORE-1619 | Documentation containing long term support informations | https://redhat.atlassian.net/browse/LCORE-1619 | |
There was a problem hiding this comment.
Correct uncountable noun.
"Information" is an uncountable noun in English and should not be pluralized as "informations".
📝 Proposed fix
-| LCORE-1619 | Documentation containing long term support informations | https://redhat.atlassian.net/browse/LCORE-1619 |
+| LCORE-1619 | Documentation containing long-term support information | https://redhat.atlassian.net/browse/LCORE-1619 |Note: This also applies the "long-term" hyphenation mentioned in an earlier comment.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| | LCORE-1619 | Documentation containing long term support informations | https://redhat.atlassian.net/browse/LCORE-1619 | | |
| | LCORE-1619 | Documentation containing long-term support information | https://redhat.atlassian.net/browse/LCORE-1619 | |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~575-~575: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...| LCORE-1619 | Documentation containing long term support informations ...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md`
at line 575, Update the table row containing "LCORE-1619" so the description
reads "Documentation containing long-term support information" instead of
"Documentation containing long term support informations": replace the plural
"informations" with the uncountable "information" and add the hyphen to
"long-term" for correct compound adjective formatting.
| # Stories created | ||
|
|
||
| | Epic | Story | Description | Link | | ||
| |------------|-------|-----------------|-----------------| | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Empty stories table suggests incomplete documentation.
The "Stories created" section contains only a table header with no story entries. If stories have not yet been created, consider adding a note (e.g., "To be created" or "Pending refinement"). If stories exist, populate the table.
Would you like me to suggest a placeholder note for this section?
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md`
around lines 583 - 587, The "Stories created" section currently has only the
table header; update the "Stories created" table under the "Stories created"
heading by either adding the missing story rows (populate Epic, Story,
Description, Link entries) or, if no stories exist yet, insert a clear
placeholder row or single-line note such as "To be created" or "Pending
refinement" so the table is not empty; edit the markdown table immediately
beneath the "Stories created" heading to include the placeholder or real
entries.
…g-backport-changes-for-releases.md Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
…g-backport-changes-for-releases.md Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (4)
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md (4)
585-587:⚠️ Potential issue | 🟡 Minor“Stories created” section is still empty.
The table header exists without entries. Add real stories or a placeholder row (e.g., “Pending refinement”).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md` around lines 585 - 587, The "Stories created" table currently has only a header and no rows; add at least one row under the header in the "Stories created" section—either real story entries with Epic/Story/Description/Link values or a placeholder row such as "| Pending refinement | - | Pending refinement | - |" so the table is not empty and readers know the status; update the table immediately below the existing header row in the supporting-backport-changes-for-releases.md file.
345-346:⚠️ Potential issue | 🟡 MinorGrammar issue remains in NOTE sentence.
Line 345 still uses “not feature nor hotfix”; use “not feature or hotfix” (or “neither feature nor hotfix”).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md` around lines 345 - 346, The NOTE sentence currently reads "the actual proposal covers just release branches, not feature nor hotfix ones." — update that phrase to correct the grammar by replacing "not feature nor hotfix" with either "not feature or hotfix" or "neither feature nor hotfix" so the sentence becomes e.g. "the actual proposal covers just release branches, not feature or hotfix ones." Ensure the revised sentence appears in the same NOTE paragraph.
575-576:⚠️ Potential issue | 🟡 MinorEpic description still has wording/grammar defects.
Line 575 still contains “long term support informations”; use “long-term support information.”
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md` around lines 575 - 576, Update the epic description text in the table entry for LCORE-1619: replace the phrase "long term support informations" with the grammatically correct "long-term support information" (update the table cell associated with LCORE-1619 so the description reads exactly "Documentation containing long-term support information").
272-274:⚠️ Potential issue | 🟡 MinorFenced code blocks still missing language specifiers.
These blocks were previously flagged and remain unresolved. Please add
textfor non-code/ascii blocks so markdownlint MD040 passes consistently.Also applies to: 354-365, 369-390, 422-469, 547-567
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md` around lines 272 - 274, Several fenced code blocks (for example the block containing "release/MAJOR.MINOR.PATCH") are missing language specifiers; update those fenced blocks to include the language "text" so markdownlint MD040 passes. Locate the plain/ascii fenced blocks (including the other instances noted in the review) and add the ```text opening fence for each, preserving the original content and closing fences.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In
`@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md`:
- Around line 416-417: The doc currently instructs creating hotfix/x.y.z+1 from
main which risks including unreleased changes; update the instruction to create
the hotfix branch from the target release branch (e.g., branch hotfix/x.y.z+1
off release/x.y.z) so the hotfix contains only released-version code, and
clarify in the text that the hotfix source must be release/x.y.z (not main).
- Around line 524-537: Update the patch-release example so it matches the
earlier guidance about cutting patch releases from the existing release branch:
replace the current checkout command pattern ("git checkout -b release/1.2.1
release/1.2.0") with the explicit flow of first checking out the existing
release branch and then creating the patch branch (e.g., checkout release/1.2.0,
then git checkout -b release/1.2.1), and adjust the surrounding explanatory text
to state that patch branches are created from the existing release branch rather
than creating a new release branch off a different base.
---
Duplicate comments:
In
`@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md`:
- Around line 585-587: The "Stories created" table currently has only a header
and no rows; add at least one row under the header in the "Stories created"
section—either real story entries with Epic/Story/Description/Link values or a
placeholder row such as "| Pending refinement | - | Pending refinement | - |" so
the table is not empty and readers know the status; update the table immediately
below the existing header row in the supporting-backport-changes-for-releases.md
file.
- Around line 345-346: The NOTE sentence currently reads "the actual proposal
covers just release branches, not feature nor hotfix ones." — update that phrase
to correct the grammar by replacing "not feature nor hotfix" with either "not
feature or hotfix" or "neither feature nor hotfix" so the sentence becomes e.g.
"the actual proposal covers just release branches, not feature or hotfix ones."
Ensure the revised sentence appears in the same NOTE paragraph.
- Around line 575-576: Update the epic description text in the table entry for
LCORE-1619: replace the phrase "long term support informations" with the
grammatically correct "long-term support information" (update the table cell
associated with LCORE-1619 so the description reads exactly "Documentation
containing long-term support information").
- Around line 272-274: Several fenced code blocks (for example the block
containing "release/MAJOR.MINOR.PATCH") are missing language specifiers; update
those fenced blocks to include the language "text" so markdownlint MD040 passes.
Locate the plain/ascii fenced blocks (including the other instances noted in the
review) and add the ```text opening fence for each, preserving the original
content and closing fences.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
Run ID: e642d223-227b-4931-865f-9ca63c0ac174
📒 Files selected for processing (1)
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (6)
- GitHub Check: Pylinter
- GitHub Check: build-pr
- GitHub Check: mypy
- GitHub Check: Konflux kflux-prd-rh02 / lightspeed-stack-on-pull-request
- GitHub Check: E2E: server mode / ci
- GitHub Check: E2E Tests for Lightspeed Evaluation job
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: blublinsky
Repo: lightspeed-core/lightspeed-stack PR: 972
File: src/models/config.py:459-513
Timestamp: 2026-01-12T10:58:50.251Z
Learning: In the lightspeed-stack repository, when a user claims a fix is done but the code still shows the original issue, verify the current state of the code before accepting the fix.
📚 Learning: 2026-01-12T10:58:50.251Z
Learnt from: blublinsky
Repo: lightspeed-core/lightspeed-stack PR: 972
File: src/models/config.py:459-513
Timestamp: 2026-01-12T10:58:50.251Z
Learning: In the lightspeed-stack repository, when a user claims a fix is done but the code still shows the original issue, verify the current state of the code before accepting the fix.
Applied to files:
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
📚 Learning: 2026-03-02T15:57:15.929Z
Learnt from: asamal4
Repo: lightspeed-core/lightspeed-stack PR: 1250
File: AGENTS.md:11-12
Timestamp: 2026-03-02T15:57:15.929Z
Learning: In lightspeed-stack's AGENTS.md, the Linting Tools section lists actual tool names (e.g., mypy, pylint, pyright, ruff, black), not make target names. For example, `check-types` is a make target that runs mypy, but mypy is the tool name documented in the Linting Tools section.
Applied to files:
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
🪛 LanguageTool
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
[style] ~185-~185: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to implement new feature planned in versio...
(REP_NEED_TO_VB)
[style] ~195-~195: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to backport the CVE from main branch to gi...
(REP_NEED_TO_VB)
[style] ~200-~200: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to backport the bug from main branch to gi...
(REP_NEED_TO_VB)
[style] ~205-~205: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to backport the CVE from version X branch ...
(REP_NEED_TO_VB)
[style] ~210-~210: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... As a Lightspeed Core Stack developer I need to backport the bug from version X branch ...
(REP_NEED_TO_VB)
[style] ~215-~215: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... ## U9 As Lightspeed Core Stack user I need to have a list of supported versions, supp...
(REP_NEED_TO_VB)
[grammar] ~290-~290: Ensure spelling is correct
Context: .... * Typical tasks on the branch: final bugfixes, documentation, version bump, packagi...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[style] ~315-~315: Three successive sentences begin with the same word. Consider rewording the sentence or use a thesaurus to find a synonym.
Context: ...ty in a backwards-compatible manner. * Increment PATCH when you make backwards-compatibl...
(ENGLISH_WORD_REPEAT_BEGINNING_RULE)
[grammar] ~345-~345: Ensure spelling is correct
Context: ...vers just release branches, not feature nor hotfix ones. ## Release branches vis...
(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)
[grammar] ~473-~473: Use a hyphen to join words.
Context: ... +-----------------+ ``` ### Cherry picking Cherry-picking is a Git operati...
(QB_NEW_EN_HYPHEN)
[uncategorized] ~575-~575: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...| LCORE-1619 | Documentation containing long term support informations ...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
[uncategorized] ~576-~576: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ....net/browse/LCORE-1619 | | LCORE-1620 | Up to date page with supported and unsupported LCS...
(EN_COMPOUND_ADJECTIVE_INTERNAL)
🪛 markdownlint-cli2 (0.22.0)
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md
[warning] 272-272: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 354-354: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 369-369: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 422-422: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
[warning] 547-547: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🔇 Additional comments (1)
docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md (1)
221-261: Clear and actionable core solution section.This section is well-structured and gives concrete operational steps (branching, CI, SemVer, review gates).
| 9. Hotfixes (if needed): create hotfix/x.y.z+1 from main, then follow same flow | ||
|
|
There was a problem hiding this comment.
Hotfix source branch is unsafe for released-version patching.
Line 416 says to create hotfix/x.y.z+1 from main; that can pull unreleased changes into a patch train. For released-version hotfixes, branch from the target release/x.y.z line instead.
🛠️ Proposed fix
-9. Hotfixes (if needed): create hotfix/x.y.z+1 from main, then follow same flow
+9. Hotfixes (if needed): create hotfix/x.y.z+1 from the target release/x.y.z branch, then follow the same flow🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md`
around lines 416 - 417, The doc currently instructs creating hotfix/x.y.z+1 from
main which risks including unreleased changes; update the instruction to create
the hotfix branch from the target release branch (e.g., branch hotfix/x.y.z+1
off release/x.y.z) so the hotfix contains only released-version code, and
clarify in the text that the hotfix source must be release/x.y.z (not main).
| ```bash | ||
| # 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 | ||
| ``` |
There was a problem hiding this comment.
Patch release example conflicts with earlier release-branch strategy.
Lines 524-537 create a new release/1.2.1 branch from release/1.2.0, but earlier guidance (Line 245) says patch releases are cut from the existing release branch. This inconsistency will confuse implementers and can fragment maintenance branches.
🛠️ Proposed fix
-# 1. Create branch from the release branch
-git checkout -b release/1.2.1 release/1.2.0
+# 1. Checkout the existing release branch
+git checkout 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
+git push origin release/1.2.0
# 4. Tag the release
git tag -a v1.2.1 -m "Release 1.2.1"
git push origin v1.2.1🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In
`@docs/design/supporting-backport-changes-for-releases/supporting-backport-changes-for-releases.md`
around lines 524 - 537, Update the patch-release example so it matches the
earlier guidance about cutting patch releases from the existing release branch:
replace the current checkout command pattern ("git checkout -b release/1.2.1
release/1.2.0") with the explicit flow of first checking out the existing
release branch and then creating the patch branch (e.g., checkout release/1.2.0,
then git checkout -b release/1.2.1), and adjust the surrounding explanatory text
to state that patch branches are created from the existing release branch rather
than creating a new release branch off a different base.
1 participant
Description
LCORE-1596: Spike document
Type of change
Tools used to create PR
Related Tickets & Documents
Summary by CodeRabbit