Cut release 3.17.12#1727
Conversation
WalkthroughThis change updates the Changelog.md file, replacing the "Unreleased" placeholder section header with a new "3.17.12" release section. A new bullet point was added under this section documenting the addition of FSL 1.1 license variants. The change consists of a single line modification plus one new line, with no code or public API alterations. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@Changelog.md`:
- Line 5: The changelog entry has a punctuation typo in the “Licensing” bullet:
the text in Changelog.md includes an extra period after “FSL 1.1.”. Update that
entry to use the same wording without the extra period so it reads consistently
as “FSL 1.1 license variants,” keeping the rest of the bullet unchanged.
🪄 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: Repository YAML (base), Organization UI (inherited)
Review profile: ASSERTIVE
Plan: Pro
Run ID: c7e23f08-1cc3-4853-bf9a-a828b5ebe3e0
📒 Files selected for processing (1)
Changelog.md
Overview
Cuts release for 3.17.12. Should pull in the latest themis.
Acceptance criteria
If this PR is successful, what impact does it have on the user experience?
Example: When users do X, Y should now happen.
Testing plan
How did you validate that this PR works? What literal steps did you take when manually checking that your code works?
Example:
This section should list concrete steps that a reviewer can sanity check and repeat on their own machine (and provide any needed test cases).
Risks
Highlight any areas that you're unsure of, want feedback on, or want reviewers to pay particular attention to.
Example: I'm not sure I did X correctly, can reviewers please double-check that for me?
Metrics
Is this change something that can or should be tracked? If so, can we do it today? And how? If its easy, do it
References
Add links to any referenced GitHub issues, Zendesk tickets, Jira tickets, Slack threads, etc.
Example:
Checklist
docs/.docs/README.msand gave consideration to how discoverable or not my documentation is.Changelog.md. If this PR did not mark a release, I added my changes into an## Unreleasedsection at the top..fossa.ymlorfossa-deps.{json.yml}, I updateddocs/references/files/*.schema.jsonAND I have updated example files used byfossa initcommand. You may also need to update these if you have added/removed new dependency type (e.g.pip) or analysis target type (e.g.poetry).docs/references/subcommands/<subcommand>.md.