Open
Conversation
Signed-off-by: Dhaval D <343411+ossdhaval@users.noreply.github.com>
Member
✅ 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. |
Contributor
📝 WalkthroughWalkthroughUpdated Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~5 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ 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 |
mo-auto
added
area-documentation
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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: Add a short “Legacy policy/exception” note in docs/EOL.md clarifying
why the v1.x.0 row does not follow the T0+12/T0+24 GA-based formula: state that
the main lifecycle formula applies only to versions >= 2.0.0, and that v1.x.0
dates (e.g., projected EOL 2026-11-14) are calculated under a legacy
schedule/contractual timeline or manual projection based on GA 2024-03-14 and
any exceptions; add this as a footnote or a parenthetical sentence next to the
v1.x.0 table row and mirror the same clarification where the T0+12/T0+24 formula
appears (lines referenced in the comment: the GA formula and the v1.x.0 row) so
the table and policy are no longer contradictory.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
| ## 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 applies to version 2.0.0 and later releases. |
Contributor
There was a problem hiding this comment.
Clarify why v1.x.0 does not follow the stated lifecycle formula.
The document now states lifecycle math (T0+12 / T0+24) and also scopes policy to 2.0.0+, but the v1.x.0 row uses a projected EOL (2026-11-14) that does not derive from the shown formula using GA 2024-03-14. Please add an explicit “legacy policy/exception” note (or footnote in the table) explaining how v1.x.0 dates are calculated, so the table and policy are not interpreted as contradictory.
Also applies to: 19-20, 28-28
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/EOL.md` at line 12, Add a short “Legacy policy/exception” note in
docs/EOL.md clarifying why the v1.x.0 row does not follow the T0+12/T0+24
GA-based formula: state that the main lifecycle formula applies only to versions
>= 2.0.0, and that v1.x.0 dates (e.g., projected EOL 2026-11-14) are calculated
under a legacy schedule/contractual timeline or manual projection based on GA
2024-03-14 and any exceptions; add this as a footnote or a parenthetical
sentence next to the v1.x.0 table row and mirror the same clarification where
the T0+12/T0+24 formula appears (lines referenced in the comment: the GA formula
and the v1.x.0 row) so the table and policy are no longer contradictory.
Contributor
There was a problem hiding this comment.
@ossdhaval, understood — no changes needed here. Thanks for the clarification!
🧠 Learnings used
Learnt from: olehbozhok
Repo: JanssenProject/jans PR: 13748
File: docs/cedarling/reference/cedarling-policy-store.md:88-94
Timestamp: 2026-04-14T12:20:54.423Z
Learning: In `docs/cedarling/reference/cedarling-policy-store.md` (and related Cedarling directory-based policy store docs), the `id("...")` annotation is documented as a hard requirement for policies even though the parser still accepts single-policy files without it (falling back to filename-derived IDs for backward compatibility). This is intentional: the docs describe only the new/recommended API, not the backward-compatible fallback. Do not flag the missing mention of the filename-fallback as an inconsistency.
Learnt from: moabu
Repo: JanssenProject/jans PR: 13060
File: CHANGELOG.md:25-26
Timestamp: 2026-01-22T14:33:53.554Z
Learning: Repo: JanssenProject/jans — For Release Please-generated PRs (chore(main): release …), CHANGELOG.md is auto-generated; avoid suggesting manual edits (e.g., duplicate/formatting cleanups) and ignore minor nits in that file.
Learnt from: misba7
Repo: JanssenProject/jans PR: 12995
File: docs/janssen-server/install/helm-install/google-gke.md:110-119
Timestamp: 2026-01-13T17:29:21.837Z
Learning: In documentation, update references to ingress-nginx (kubernetes/ingress-nginx) to reflect its retirement: Kubernetes announced a terminal maintenance window through March 2026 with no further releases, bug fixes, or security updates after that. Treat ingress-nginx as retired or legacy in docs, and clearly denote current status and end-of-life timelines where relevant.
Learnt from: yuriyz
Repo: JanssenProject/jans PR: 13429
File: docs/janssen-server/auth-server/client-management/client-configuration.md:38-38
Timestamp: 2026-03-06T09:40:20.648Z
Learning: Documentation: In docs related to client configuration, clearly state that native app clients may allow any URI scheme for redirect URIs (including javascript:, data:, etc.), while web clients must use HTTPS with a non-blank host or HTTP limited to localhost/127.0.0.1. Emphasize that this behavior aligns with RFC 8252 (OAuth 2.0 for Native Apps) and that documentation should not flag the “any scheme allowed for native client” approach as incorrect.
Learnt from: olehbozhok
Repo: JanssenProject/jans PR: 13544
File: docs/cedarling/quick-start/cedarling-quick-start.md:312-329
Timestamp: 2026-03-20T19:07:30.490Z
Learning: In this repo’s MkDocs markdown documentation, do not add blank lines around fenced code blocks when the fenced block is nested inside a numbered list item (the fence is indented as part of the list item, e.g., typically by 3+ spaces). Adding blank lines can break Markdown list continuation in MkDocs and cause the following paragraph to detach from the list item. In this specific list-nested/fenced-block scenario, do not flag markdownlint’s MD031 (“fenced code blocks should be surrounded by blank lines”).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #13568
Summary by CodeRabbit