Conversation
Signed-off-by: Dhaval D <343411+ossdhaval@users.noreply.github.com>
Signed-off-by: Dhaval D <343411+ossdhaval@users.noreply.github.com>
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
📝 WalkthroughWalkthroughUpdated Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 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/EOL.md`:
- Line 12: Replace the awkward sentence "This is applicable for version 2.0.0
and later releases." with a clearer phrasing such as "This applies to version
2.0.0 and later; earlier releases follow the legacy lifecycle." so it reads
smoothly and explicitly labels older versions as the "legacy lifecycle."
- Line 30: The table row for "v2.x.x" currently uses the GA column to show
"**Under development**", which presents a future date as an actual release;
update the cell for the v2.x.x row (the row containing the "v2.x.x" identifier
and the GA column) to use a forward-looking label such as "**Planned GA**" (or
similar) instead of "**Under development**" so the table clearly indicates this
is a planned/future GA rather than an actual release.
- Line 31: The table row for release identifier "v1.x.0" incorrectly shows
status "Active" despite EOM being 2025-04-10; update the status cell for
"v1.x.0" to reflect the maintenance phase (e.g., "Maintenance" or
"Maintenance-only") so the support status matches the documented EOM date and
expectations for bug-fix support.
| ## 1. Lifecycle Overview | ||
|
|
||
| Our End of Life (EOL) policy is designed to provide a predictable schedule for support and upgrades. The lifecycle of any major version is calculated based on its original **General Availability (GA)** date. | ||
| Our End of Life (EOL) policy is designed to provide a predictable schedule for support and upgrades. The lifecycle of any major version is calculated based on its original **General Availability (GA)** date. This is applicable for version 2.0.0 and later releases. |
There was a problem hiding this comment.
Clarify scope sentence for readability and precision.
“This is applicable for…” is awkward; use “This applies to version 2.0.0 and later” and explicitly call older versions “legacy lifecycle” to avoid interpretation drift.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/EOL.md` at line 12, Replace the awkward sentence "This is applicable for
version 2.0.0 and later releases." with a clearer phrasing such as "This applies
to version 2.0.0 and later; earlier releases follow the legacy lifecycle." so it
reads smoothly and explicitly labels older versions as the "legacy lifecycle."
| |------------|-------------------|--------------------|-----------------------|-----------------------| | ||
| | **v2.x.x** | 2026-04-10 | 2027-04-10 | 2028-04-10 | **Under development** | | ||
| | **v1.x.0** | 2024-03-14 | 2025-04-10 | 2026-03-14 | **Active** | | ||
| | **v2.x.x** | 2026-05-01 | 2027-05-01 | 2028-05-01 | **Under development** | |
There was a problem hiding this comment.
Avoid labeling a future date as an actual GA release date.
v2.x.x is marked Under development, but the column is “Release Date (GA)”. If GA is in the future, this should be labeled as Planned GA (or similar) to avoid presenting forecast data as an actual release milestone.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/EOL.md` at line 30, The table row for "v2.x.x" currently uses the GA
column to show "**Under development**", which presents a future date as an
actual release; update the cell for the v2.x.x row (the row containing the
"v2.x.x" identifier and the GA column) to use a forward-looking label such as
"**Planned GA**" (or similar) instead of "**Under development**" so the table
clearly indicates this is a planned/future GA rather than an actual release.
| | **v2.x.x** | 2026-04-10 | 2027-04-10 | 2028-04-10 | **Under development** | | ||
| | **v1.x.0** | 2024-03-14 | 2025-04-10 | 2026-03-14 | **Active** | | ||
| | **v2.x.x** | 2026-05-01 | 2027-05-01 | 2028-05-01 | **Under development** | | ||
| | **v1.x.0** | 2024-03-14 | 2025-04-10 | 2026-11-14 | **Active** | |
There was a problem hiding this comment.
Status should reflect maintenance phase after EOM.
For v1.x.0, EOM is 2025-04-10, so by the documented support model this version is in maintenance-only support. “Active” is too broad and can mislead users about bug-fix expectations.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/EOL.md` at line 31, The table row for release identifier "v1.x.0"
incorrectly shows status "Active" despite EOM being 2025-04-10; update the
status cell for "v1.x.0" to reflect the maintenance phase (e.g., "Maintenance"
or "Maintenance-only") so the support status matches the documented EOM date and
expectations for bug-fix support.
Signed-off-by: Dhaval D <343411+ossdhaval@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (2)
docs/EOL.md (2)
30-30:⚠️ Potential issue | 🟠 MajorUpdate v1.x.0 status to reflect post-EOM phase.
Line 30 still marks
v1.x.0as Active even though EOM is2025-04-10; this is misleading for support expectations and should beMaintenance(orMaintenance-only).🛠️ Suggested edit
-| **v1.x.0** | 2024-03-14 | 2025-04-10 | 2026-11-14 (Projected)| **Active** | +| **v1.x.0** | 2024-03-14 | 2025-04-10 | 2026-11-14 (Projected)| **Maintenance** |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/EOL.md` at line 30, The table row for the release labeled "v1.x.0" still shows the Status as "Active" despite EOM date 2025-04-10; update that row (the "v1.x.0" entry) to set the Status column to "Maintenance" or "Maintenance-only" to reflect post-EOM support expectations and ensure the rendered table matches the EOM date.
12-12:⚠️ Potential issue | 🟡 MinorTighten lifecycle scope wording for clarity.
Line 12 phrasing (“This is applicable for...”) is awkward; prefer a direct statement that clearly separates 2.x+ from legacy versions.
✍️ Suggested edit
-Our End of Life (EOL) policy is designed to provide a predictable schedule for support and upgrades. The lifecycle of any major version is calculated based on its original **General Availability (GA)** date. This is applicable for version 2.0.0 and later releases. +Our End of Life (EOL) policy is designed to provide a predictable schedule for support and upgrades. The lifecycle of any major version is calculated from its original **General Availability (GA)** date. This applies to version 2.0.0 and later releases; earlier versions follow the legacy lifecycle.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/EOL.md` at line 12, Reword the awkward sentence "This is applicable for version 2.0.0 and later releases." to a direct, unambiguous statement clarifying scope: replace it with something like "This policy applies to major versions 2.0.0 and later; legacy versions prior to 2.0.0 follow their previous lifecycle rules." Keep the surrounding references to "General Availability (GA)" intact so the lifecycle calculation based on the GA date remains clear.
🤖 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/EOL.md`:
- Line 20: Update the misspelled word in the EOL milestone table row: find the
cell containing the text "End of maintenence support." and correct "maintenence"
to "maintenance" so it reads "End of maintenance support."; ensure the
surrounding formatting and spacing of the Markdown table row (including the
"$T_0 + 24$ Months" column) remain unchanged.
---
Duplicate comments:
In `@docs/EOL.md`:
- Line 30: The table row for the release labeled "v1.x.0" still shows the Status
as "Active" despite EOM date 2025-04-10; update that row (the "v1.x.0" entry) to
set the Status column to "Maintenance" or "Maintenance-only" to reflect post-EOM
support expectations and ensure the rendered table matches the EOM date.
- Line 12: Reword the awkward sentence "This is applicable for version 2.0.0 and
later releases." to a direct, unambiguous statement clarifying scope: replace it
with something like "This policy applies to major versions 2.0.0 and later;
legacy versions prior to 2.0.0 follow their previous lifecycle rules." Keep the
surrounding references to "General Availability (GA)" intact so the lifecycle
calculation based on the GA date remains clear.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Signed-off-by: Dhaval D <343411+ossdhaval@users.noreply.github.com>
There was a problem hiding this comment.
♻️ Duplicate comments (2)
docs/EOL.md (2)
30-30:⚠️ Potential issue | 🟠 MajorStatus label conflicts with the documented support phase.
Line 30 marks
v1.x.0as Active, but its EOM is 2025-04-10, which indicates maintenance-only support rather than active/full support.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/EOL.md` at line 30, Update the status label for the v1.x.0 entry so it matches its documented end-of-maintenance date (EOM 2025-04-10); replace the conflicting "Active" label for "v1.x.0" with a maintenance-appropriate label such as "Maintenance" or "Maintenance-only" and ensure the table row for "v1.x.0" clearly reflects maintenance-phase support consistent with the EOM column.
12-12:⚠️ Potential issue | 🟡 MinorClarify the lifecycle scope sentence.
Line 12 still reads awkwardly (“This is applicable for…”). Prefer a direct form like “This applies to version 2.0.0 and later; earlier releases follow the legacy lifecycle.”
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/EOL.md` at line 12, Replace the awkward sentence "This is applicable for version 2.0.0 and later releases." with a clearer, direct form; update the line in the EOL.md paragraph so it reads something like: "This applies to version 2.0.0 and later; earlier releases follow the legacy lifecycle." Ensure the new sentence keeps the same context about GA-based lifecycle calculation.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/EOL.md`:
- Line 30: Update the status label for the v1.x.0 entry so it matches its
documented end-of-maintenance date (EOM 2025-04-10); replace the conflicting
"Active" label for "v1.x.0" with a maintenance-appropriate label such as
"Maintenance" or "Maintenance-only" and ensure the table row for "v1.x.0"
clearly reflects maintenance-phase support consistent with the EOM column.
- Line 12: Replace the awkward sentence "This is applicable for version 2.0.0
and later releases." with a clearer, direct form; update the line in the EOL.md
paragraph so it reads something like: "This applies to version 2.0.0 and later;
earlier releases follow the legacy lifecycle." Ensure the new sentence keeps the
same context about GA-based lifecycle calculation.
Signed-off-by: Dhaval D <343411+ossdhaval@users.noreply.github.com>
There was a problem hiding this comment.
♻️ Duplicate comments (1)
docs/EOL.md (1)
30-30:⚠️ Potential issue | 🟠 Major
v1.x.0row is inconsistent with the documented lifecycle model.Given GA =
2024-03-14,$T_0 + 24$ Monthsimplies EOL2026-03-14, not2026-11-14 (Projected). Also, with EOM already at2025-04-10, status should reflect maintenance phase rather than broadActive.Suggested fix
-| **v1.x.0** | 2024-03-14 | 2025-04-10 | 2026-11-14 (Projected)| **Active** | +| **v1.x.0** | 2024-03-14 | 2025-04-10 | 2026-03-14 | **Maintenance** |🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/EOL.md` at line 30, The v1.x.0 table row entry ("| **v1.x.0** | 2024-03-14 | 2025-04-10 | 2026-11-14 (Projected)| **Active** |") is inconsistent with the lifecycle rules: change the EOL date from "2026-11-14 (Projected)" to "2026-03-14" (GA + 24 months) and update the status from "**Active**" to "**Maintenance**" to reflect that EOM has passed; ensure the edited row preserves the same column separators and formatting as the surrounding table.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@docs/EOL.md`:
- Line 30: The v1.x.0 table row entry ("| **v1.x.0** | 2024-03-14 |
2025-04-10 | 2026-11-14 (Projected)| **Active** |") is
inconsistent with the lifecycle rules: change the EOL date from "2026-11-14
(Projected)" to "2026-03-14" (GA + 24 months) and update the status from
"**Active**" to "**Maintenance**" to reflect that EOM has passed; ensure the
edited row preserves the same column separators and formatting as the
surrounding table.
|
Closing this PR due to an unverified commit. Substituted by #13830 . |
closes #13568
Summary by CodeRabbit