docs: release notes for February 2026 releases#2315
docs: release notes for February 2026 releases#2315klausundklaus wants to merge 2 commits intoLightprotocol:mainfrom
Conversation
📝 WalkthroughWalkthroughAdds or updates CHANGELOG.md files across multiple sdk-libs packages to document recent fixes and features: canonical ATA bump enforcement, max_top_up default change to u16::MAX, removal/clarification of some photon Configuration APIs, create_accounts() feature announcement, and related token/fee_payer fixes. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@sdk-libs/instruction-decoder/CHANGELOG.md`:
- Around line 5-9: Update the CHANGELOG entry header to include the package
version alongside the date (e.g., change "## 2026-02-17" to the Keep a Changelog
style "## [0.22.0] - 2026-02-17") so consumers can map the note about
`max_top_up` default changes to the corresponding release; apply the same
versioned header format to all other CHANGELOG files in this PR to ensure
consistency with the PR objective mentioning light-client@0.22.0 and related
packages.
In `@sdk-libs/macros/CHANGELOG.md`:
- Around line 11-13: Update the CHANGELOG entry "Enforces canonical bump in ATA
verification. (`#2249`)" to clarify what "canonical bump" means for readers:
expand the line to something like "Enforces canonical bump (seed 255) in ATA
verification to ensure deterministic PDA/ATA derivation" and optionally add a
short parenthetical or link to Solana PDA/ATA docs; reference the exact phrase
"canonical bump" and "ATA verification" so the wording is updated in the
CHANGELOG.md entry.
In `@sdk-libs/photon-api/CHANGELOG.md`:
- Around line 22-24: The changelog entry "V1 compatibility in mint action layout
removed. (`#2226`)" is a breaking change and must be recategorized; edit
CHANGELOG.md to move that bullet out of the "### Fixes" section into a "###
Breaking Changes" section (create it if missing), update the bullet to indicate
removal and reference commit/PR (e.g., commit 221c1aa5 / `#2226`) and ensure the
text clearly states V1 compatibility was removed so users are warned of the
breaking change.
In `@sdk-libs/program-test/CHANGELOG.md`:
- Around line 5-15: The CHANGELOG currently lists two dated release entries
without explicit version headings, which makes it hard for users to map changes
to package versions; update the file (CHANGELOG.md) to add explicit version
headers for each release (for example add "## [0.22.0] - 2026-02-17" above the
Feb 17 fixes and "## [0.21.0] - 2026-02-10" above the Feb 10 features), ensure
each bullet remains under the correct version header and follow the existing
formatting convention so each release entry clearly shows its version and date.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (11)
sdk-libs/account-pinocchio/CHANGELOG.mdsdk-libs/account/CHANGELOG.mdsdk-libs/client/CHANGELOG.mdsdk-libs/compressed-token-sdk/CHANGELOG.mdsdk-libs/event/CHANGELOG.mdsdk-libs/instruction-decoder/CHANGELOG.mdsdk-libs/macros/CHANGELOG.mdsdk-libs/photon-api/CHANGELOG.mdsdk-libs/program-test/CHANGELOG.mdsdk-libs/token-pinocchio/CHANGELOG.mdsdk-libs/token-sdk/CHANGELOG.md
| ## 2026-02-17 | ||
|
|
||
| ### Fixes | ||
|
|
||
| - `max_top_up` defaults to `u16::MAX` instead of `0` in instruction builders. (#2279) |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider including version numbers alongside dates.
The entry uses a date-based format (2026-02-17) but doesn't specify which version this corresponds to. According to the PR objectives, this release includes light-client@0.22.0 and related packages. Including the version number (e.g., ## [0.22.0] - 2026-02-17) would improve traceability and align with Keep a Changelog conventions, making it easier for users to correlate CHANGELOG entries with installed versions.
📋 Suggested format with version number
-## 2026-02-17
+## [0.22.0] - 2026-02-17Note: This observation applies to all CHANGELOG files in this PR.
📝 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.
| ## 2026-02-17 | |
| ### Fixes | |
| - `max_top_up` defaults to `u16::MAX` instead of `0` in instruction builders. (#2279) | |
| ## [0.22.0] - 2026-02-17 | |
| ### Fixes | |
| - `max_top_up` defaults to `u16::MAX` instead of `0` in instruction builders. (`#2279`) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@sdk-libs/instruction-decoder/CHANGELOG.md` around lines 5 - 9, Update the
CHANGELOG entry header to include the package version alongside the date (e.g.,
change "## 2026-02-17" to the Keep a Changelog style "## [0.22.0] - 2026-02-17")
so consumers can map the note about `max_top_up` default changes to the
corresponding release; apply the same versioned header format to all other
CHANGELOG files in this PR to ensure consistency with the PR objective
mentioning light-client@0.22.0 and related packages.
| ### Fixes | ||
|
|
||
| - Enforces canonical bump in ATA verification. (#2249) |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider clarifying "canonical bump" terminology.
The fix mentions "Enforces canonical bump in ATA verification," but developers unfamiliar with Solana PDA (Program Derived Address) conventions might not immediately understand what "canonical bump" means. Consider adding a brief explanation or link to documentation. For example: "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic address derivation."
This helps developers understand the security/correctness implications of the fix.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@sdk-libs/macros/CHANGELOG.md` around lines 11 - 13, Update the CHANGELOG
entry "Enforces canonical bump in ATA verification. (`#2249`)" to clarify what
"canonical bump" means for readers: expand the line to something like "Enforces
canonical bump (seed 255) in ATA verification to ensure deterministic PDA/ATA
derivation" and optionally add a short parenthetical or link to Solana PDA/ATA
docs; reference the exact phrase "canonical bump" and "ATA verification" so the
wording is updated in the CHANGELOG.md entry.
| ### Fixes | ||
|
|
||
| - **`external/photon` git submodule.** The Photon OpenAPI spec (`external/photon/src/openapi/specs/api.yaml`) is now pulled in as a submodule. Client types are pre-generated by [progenitor](https://github.com/oxidecomputer/progenitor) and checked in as `src/codegen.rs`. To regenerate after spec changes: `cargo build -p photon-api --features generate`. Generation deps (progenitor, regress, etc.) are behind the optional `generate` feature so they don't affect normal builds or CI. | ||
| - V1 compatibility in mint action layout removed. (#2226) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Search for PR `#2226` references in commits and code
rg "#2226" --type md --type rs --type ts --type js -A 2 -B 2Repository: Lightprotocol/light-protocol
Length of output: 98
🏁 Script executed:
# Search for mint action layout related code
rg "mint.*action.*layout" -i --type md --type rs --type ts --type js -A 2Repository: Lightprotocol/light-protocol
Length of output: 98
🏁 Script executed:
# Search for V1 compatibility references
rg "V1.*compat|v1.*compat" -i --type md --type rs --type ts --type js -A 2 -B 2Repository: Lightprotocol/light-protocol
Length of output: 98
🏁 Script executed:
# Look for breaking change indicators in commit messages
git log --oneline --all | grep -iE "#2226|mint.*action|v1.*compat"Repository: Lightprotocol/light-protocol
Length of output: 205
🏁 Script executed:
# Get full commit details for the V1 compatibility removal
git show 221c1aa5 --statRepository: Lightprotocol/light-protocol
Length of output: 1918
🏁 Script executed:
# Get the actual diff to see what was removed
git show 221c1aa5 --no-stat | head -100Repository: Lightprotocol/light-protocol
Length of output: 111
🏁 Script executed:
# Search for any deprecation notices or V1/V2 documentation
rg "V1|V2|v1|v2" sdk-libs/photon-api --type md -B 2 -A 2 | head -60Repository: Lightprotocol/light-protocol
Length of output: 685
🏁 Script executed:
# Check if there's any migration guide or breaking changes note
fd "CHANGELOG\|MIGRATION\|BREAKING\|README" sdk-libs/photon-api --type fRepository: Lightprotocol/light-protocol
Length of output: 54
Recategorize to Breaking Changes: V1 compatibility removal is a breaking change
The commit 221c1aa5 with message "chore: rm v1 compatibility in mint action layout" is explicitly removing functionality. Removals are breaking changes—any code relying on V1 compatibility will fail after this update. While the commit type is "chore" (maintenance), this should be listed under Breaking Changes, not Fixes, to alert users to the breaking nature of this update. Fixes preserve compatibility while correcting bugs; removals do not.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@sdk-libs/photon-api/CHANGELOG.md` around lines 22 - 24, The changelog entry
"V1 compatibility in mint action layout removed. (`#2226`)" is a breaking change
and must be recategorized; edit CHANGELOG.md to move that bullet out of the "###
Fixes" section into a "### Breaking Changes" section (create it if missing),
update the bullet to indicate removal and reference commit/PR (e.g., commit
221c1aa5 / `#2226`) and ensure the text clearly states V1 compatibility was
removed so users are warned of the breaking change.
| ## 2026-02-17 | ||
|
|
||
| ### Fixes | ||
|
|
||
| - Enforces canonical bump in ATA verification. (#2249) | ||
|
|
||
| ## 2026-02-10 | ||
|
|
||
| ### Features | ||
|
|
||
| - `compressed_mint` photon API support. (#2198) |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Multiple release entries increase the value of version numbers.
This CHANGELOG documents two separate releases (Feb 17 and Feb 10), which according to the PR objectives correspond to versions 0.22.0 and 0.21.0 respectively. With multiple releases, version numbers become even more important for users to identify which features and fixes are in their installed version.
📋 Suggested format for multiple releases
-## 2026-02-17
+## [0.22.0] - 2026-02-17
### Fixes
- Enforces canonical bump in ATA verification. (`#2249`)
-## 2026-02-10
+## [0.21.0] - 2026-02-10
### Features
- `compressed_mint` photon API support. (`#2198`)📝 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.
| ## 2026-02-17 | |
| ### Fixes | |
| - Enforces canonical bump in ATA verification. (#2249) | |
| ## 2026-02-10 | |
| ### Features | |
| - `compressed_mint` photon API support. (#2198) | |
| ## [0.22.0] - 2026-02-17 | |
| ### Fixes | |
| - Enforces canonical bump in ATA verification. (`#2249`) | |
| ## [0.21.0] - 2026-02-10 | |
| ### Features | |
| - `compressed_mint` photon API support. (`#2198`) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@sdk-libs/program-test/CHANGELOG.md` around lines 5 - 15, The CHANGELOG
currently lists two dated release entries without explicit version headings,
which makes it hard for users to map changes to package versions; update the
file (CHANGELOG.md) to add explicit version headers for each release (for
example add "## [0.22.0] - 2026-02-17" above the Feb 17 fixes and "## [0.21.0] -
2026-02-10" above the Feb 10 features), ensure each bullet remains under the
correct version header and follow the existing formatting convention so each
release entry clearly shows its version and date.
There was a problem hiding this comment.
Actionable comments posted: 3
♻️ Duplicate comments (5)
sdk-libs/account-pinocchio/CHANGELOG.md (1)
15-15: 🧹 Nitpick | 🔵 TrivialClarify "canonical bump" terminology.
Consider expanding "canonical bump" to: "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic address derivation." This would align with the clarification suggested in the previous review comment on the macros changelog and improve consistency across all affected packages in this PR.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk-libs/account-pinocchio/CHANGELOG.md` at line 15, Update the changelog entry "Enforces canonical bump in ATA verification. (`#2249`)" to the clearer wording "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic address derivation." Keep the PR reference (`#2249`) intact and apply the same phrasing pattern used in the macros changelog for consistency across packages.sdk-libs/macros/CHANGELOG.md (1)
21-21: 🧹 Nitpick | 🔵 TrivialThe past review comment about canonical bump terminology remains valid.
As noted in the previous review, "canonical bump" should be clarified. The suggestion to expand it to "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic PDA/ATA derivation" would help developers understand the security and correctness implications.
This same clarification should be applied consistently across all changelogs in this PR that mention canonical bump (account, account-pinocchio, token-sdk, token-pinocchio).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk-libs/macros/CHANGELOG.md` at line 21, The changelog entry "Enforces canonical bump in ATA verification. (`#2249`)" is ambiguous—update it to read "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic PDA/ATA derivation" and apply the same expanded wording wherever "canonical bump" appears in this PR (specifically in the changelogs for account, account-pinocchio, token-sdk, token-pinocchio) so the security/derivation implication is explicit; keep the PR number and surrounding metadata intact while replacing the short phrase with the full clarified text.sdk-libs/account/CHANGELOG.md (1)
15-15: 🧹 Nitpick | 🔵 TrivialClarify "canonical bump" terminology for better developer understanding.
The term "canonical bump" may not be immediately clear to developers unfamiliar with Solana PDA (Program Derived Address) conventions. Consider expanding this to: "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic address derivation."
This same terminology issue appears across multiple changelog files (token-sdk, token-pinocchio, account-pinocchio, macros) and was previously flagged in the macros changelog review.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk-libs/account/CHANGELOG.md` at line 15, The changelog entry uses the ambiguous phrase "canonical bump" in the line "Enforces canonical bump in ATA verification" — update that entry to explicitly state the meaning, e.g. "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic address derivation," and apply the same clarified wording to the matching changelog lines that use "canonical bump" in related modules (token-sdk, token-pinocchio, account-pinocchio, macros) so all occurrences of "canonical bump" and the phrase "ATA verification" are replaced or expanded to include "(seed 255)" and a brief note about deterministic PDA derivation.sdk-libs/token-sdk/CHANGELOG.md (1)
29-29: 🧹 Nitpick | 🔵 TrivialClarify "canonical bump" terminology for consistency.
To maintain consistency with the clarification suggestions across other changelogs in this PR, consider expanding: "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic address derivation."
This would align with the improvements suggested for account, account-pinocchio, token-pinocchio, and macros changelogs.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk-libs/token-sdk/CHANGELOG.md` at line 29, Update the changelog entry that currently reads "Enforces canonical bump in ATA verification. (`#2249`)" to explicitly mention the seed and purpose: replace that line with "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic address derivation. (`#2249`)" so it matches the clarifying wording used in other changelogs (account, account-pinocchio, token-pinocchio, macros) and improves consistency and clarity.sdk-libs/token-pinocchio/CHANGELOG.md (1)
17-17: 🧹 Nitpick | 🔵 TrivialClarify "canonical bump" terminology.
As with other changelogs in this PR, "canonical bump" could be expanded for clarity. Consider: "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic address derivation."
This terminology appears in multiple files (account, account-pinocchio, macros, token-sdk) and should be consistently clarified across the codebase.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@sdk-libs/token-pinocchio/CHANGELOG.md` at line 17, Update the changelog entry text to expand "canonical bump" for clarity: replace the phrase "Enforces canonical bump in ATA verification." with a more explicit description like "Enforces canonical bump (seed 255) in ATA verification to ensure deterministic address derivation." and apply the same wording consistently across the related files/entries that mention "canonical bump" (account, account-pinocchio, macros, token-sdk) so all references use the clarified terminology.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@sdk-libs/client/CHANGELOG.md`:
- Around line 5-6: The changelog uses date-only headings (e.g., "##
2026-02-27"); update each date header to include the package version in
parentheses (e.g., change "## 2026-02-27" to "## 2026-02-27 (v0.23.0)") so
releases are traceable to tags/PRs—find and edit the three date headers matching
the pattern "## YYYY-MM-DD" and append the corresponding semantic version string
for each release, keeping the rest of the content unchanged and following the
same formatting convention for future entries.
In `@sdk-libs/macros/CHANGELOG.md`:
- Line 11: Remove the misplaced "Forester dashboard with compression
improvements. (`#2310`)" entry from sdk-libs/macros/CHANGELOG.md: delete that line
(the duplicate Forester dashboard changelog entry) because the feature belongs
in the client package; ensure the client changelog
(sdk-libs/client/CHANGELOG.md) retains the detailed entry ("Forester dashboard
with compression improvements, pending state tracking, and eligibility checks")
and do not add any other Forester dashboard text to the macros changelog or
other macros docs.
In `@sdk-libs/token-client/CHANGELOG.md`:
- Line 9: Add a short migration note to the CHANGELOG.md explaining the breaking
change: state that the field max_top_up was removed from the instruction structs
and authority mutability/wire format were aligned with pinocchio, and include a
concise before/after example showing the old instruction including max_top_up
and the new instruction without it plus the updated authority handling;
reference the specific symbol names (max_top_up, "instruction structs", and
pinocchio alignment) so users can map the change to their code and follow the
same pattern used in the token-sdk changelog.
---
Duplicate comments:
In `@sdk-libs/account-pinocchio/CHANGELOG.md`:
- Line 15: Update the changelog entry "Enforces canonical bump in ATA
verification. (`#2249`)" to the clearer wording "Enforces canonical bump (seed
255) in ATA verification to ensure deterministic address derivation." Keep the
PR reference (`#2249`) intact and apply the same phrasing pattern used in the
macros changelog for consistency across packages.
In `@sdk-libs/account/CHANGELOG.md`:
- Line 15: The changelog entry uses the ambiguous phrase "canonical bump" in the
line "Enforces canonical bump in ATA verification" — update that entry to
explicitly state the meaning, e.g. "Enforces canonical bump (seed 255) in ATA
verification to ensure deterministic address derivation," and apply the same
clarified wording to the matching changelog lines that use "canonical bump" in
related modules (token-sdk, token-pinocchio, account-pinocchio, macros) so all
occurrences of "canonical bump" and the phrase "ATA verification" are replaced
or expanded to include "(seed 255)" and a brief note about deterministic PDA
derivation.
In `@sdk-libs/macros/CHANGELOG.md`:
- Line 21: The changelog entry "Enforces canonical bump in ATA verification.
(`#2249`)" is ambiguous—update it to read "Enforces canonical bump (seed 255) in
ATA verification to ensure deterministic PDA/ATA derivation" and apply the same
expanded wording wherever "canonical bump" appears in this PR (specifically in
the changelogs for account, account-pinocchio, token-sdk, token-pinocchio) so
the security/derivation implication is explicit; keep the PR number and
surrounding metadata intact while replacing the short phrase with the full
clarified text.
In `@sdk-libs/token-pinocchio/CHANGELOG.md`:
- Line 17: Update the changelog entry text to expand "canonical bump" for
clarity: replace the phrase "Enforces canonical bump in ATA verification." with
a more explicit description like "Enforces canonical bump (seed 255) in ATA
verification to ensure deterministic address derivation." and apply the same
wording consistently across the related files/entries that mention "canonical
bump" (account, account-pinocchio, macros, token-sdk) so all references use the
clarified terminology.
In `@sdk-libs/token-sdk/CHANGELOG.md`:
- Line 29: Update the changelog entry that currently reads "Enforces canonical
bump in ATA verification. (`#2249`)" to explicitly mention the seed and purpose:
replace that line with "Enforces canonical bump (seed 255) in ATA verification
to ensure deterministic address derivation. (`#2249`)" so it matches the
clarifying wording used in other changelogs (account, account-pinocchio,
token-pinocchio, macros) and improves consistency and clarity.
ℹ️ Review info
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (8)
sdk-libs/account-pinocchio/CHANGELOG.mdsdk-libs/account/CHANGELOG.mdsdk-libs/client/CHANGELOG.mdsdk-libs/compressed-token-sdk/CHANGELOG.mdsdk-libs/macros/CHANGELOG.mdsdk-libs/token-client/CHANGELOG.mdsdk-libs/token-pinocchio/CHANGELOG.mdsdk-libs/token-sdk/CHANGELOG.md
| ## 2026-02-27 | ||
|
|
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider adding package version labels next to date headers.
Using date-only headings makes cross-referencing release tags harder. Adding version info (e.g., ## 2026-02-27 (v0.23.0)) would improve traceability with GitHub releases and PR release notes.
Also applies to: 11-12, 22-22
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@sdk-libs/client/CHANGELOG.md` around lines 5 - 6, The changelog uses
date-only headings (e.g., "## 2026-02-27"); update each date header to include
the package version in parentheses (e.g., change "## 2026-02-27" to "##
2026-02-27 (v0.23.0)") so releases are traceable to tags/PRs—find and edit the
three date headers matching the pattern "## YYYY-MM-DD" and append the
corresponding semantic version string for each release, keeping the rest of the
content unchanged and following the same formatting convention for future
entries.
|
|
||
| - 1-byte discriminator support via `#[light_pinocchio(discriminator = [...])]` attribute. Supports variable-length discriminators (1-8 bytes). (#2302) | ||
| - `create_accounts()` unified function replaces multiple separate code generation paths for PDAs, mints, tokens, and ATAs. (#2287) | ||
| - Forester dashboard with compression improvements. (#2310) |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, explore the repository structure
git ls-files | head -20Repository: Lightprotocol/light-protocol
Length of output: 623
🏁 Script executed:
# Check the full CHANGELOG.md to understand context
cat -n sdk-libs/macros/CHANGELOG.md | head -40Repository: Lightprotocol/light-protocol
Length of output: 851
🏁 Script executed:
# Search for references to PR `#2310` or "Forester" in the repo
rg '#2310|Forester' --type-list | head -5
rg '#2310|Forester' -iRepository: Lightprotocol/light-protocol
Length of output: 50792
🏁 Script executed:
# Check git history for recent changes to this file
git log --oneline sdk-libs/macros/CHANGELOG.md | head -5Repository: Lightprotocol/light-protocol
Length of output: 125
🏁 Script executed:
# Search for "forester" references in the entire codebase to understand scope
fd -type f -name "*.md" -o -name "*.rs" | xargs rg -i "forester" 2>/dev/null | head -20Repository: Lightprotocol/light-protocol
Length of output: 1918
🏁 Script executed:
# Check if PR `#2310` made changes to the macros package itself
grep -r "2310\|#2310" sdk-libs/macros --include="*.md" --include="*.rs"Repository: Lightprotocol/light-protocol
Length of output: 160
🏁 Script executed:
# Compare entries between both changelogs
echo "=== sdk-libs/macros/CHANGELOG.md ===" && rg -A1 -B1 "Forester dashboard" sdk-libs/macros/CHANGELOG.md
echo "=== sdk-libs/client/CHANGELOG.md ===" && rg -A1 -B1 "Forester dashboard" sdk-libs/client/CHANGELOG.mdRepository: Lightprotocol/light-protocol
Length of output: 447
🏁 Script executed:
# Check what files the macros package typically documents
ls -la sdk-libs/macros/docs/ 2>/dev/null | head -20Repository: Lightprotocol/light-protocol
Length of output: 477
🏁 Script executed:
# Read the CLAUDE.md guidelines
cat sdk-libs/macros/docs/CLAUDE.mdRepository: Lightprotocol/light-protocol
Length of output: 7269
Remove the Forester dashboard entry from the macros changelog.
This entry is misplaced. The Forester dashboard feature is documented in sdk-libs/client/CHANGELOG.md (with more detail: "Forester dashboard with compression improvements, pending state tracking, and eligibility checks"), not in the macros package.
Forester is a runtime compression/operational tool separate from the macros package, which provides compile-time code generation for account data structures. While macros documentation mentions foresters as users of the idempotent mint feature (handling already-compressed mints), the dashboard itself is not a macros feature. Move this entry to the client changelog only or remove the duplicate.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@sdk-libs/macros/CHANGELOG.md` at line 11, Remove the misplaced "Forester
dashboard with compression improvements. (`#2310`)" entry from
sdk-libs/macros/CHANGELOG.md: delete that line (the duplicate Forester dashboard
changelog entry) because the feature belongs in the client package; ensure the
client changelog (sdk-libs/client/CHANGELOG.md) retains the detailed entry
("Forester dashboard with compression improvements, pending state tracking, and
eligibility checks") and do not add any other Forester dashboard text to the
macros changelog or other macros docs.
|
|
||
| ### Breaking Changes | ||
|
|
||
| - `max_top_up` removed from instruction structs. Authority mutability and wire format aligned with pinocchio. (#2301) |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Consider adding migration guidance for the breaking change.
While the breaking change is noted, developers upgrading token-client may benefit from a brief before/after example or migration note, similar to what's provided in the token-sdk changelog (lines 9-12). If token-client's API directly exposes these instruction structs, explicit migration guidance would help users adapt their code.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@sdk-libs/token-client/CHANGELOG.md` at line 9, Add a short migration note to
the CHANGELOG.md explaining the breaking change: state that the field max_top_up
was removed from the instruction structs and authority mutability/wire format
were aligned with pinocchio, and include a concise before/after example showing
the old instruction including max_top_up and the new instruction without it plus
the updated authority handling; reference the specific symbol names (max_top_up,
"instruction structs", and pinocchio alignment) so users can map the change to
their code and follow the same pattern used in the token-sdk changelog.
1 participant
Release Notes - February 2026
Packages covered
Feb 27:
Feb 22:
Feb 18:
Feb 17:
Feb 10:
CHANGELOGs updated
sdk-libs/client/CHANGELOG.mdsdk-libs/photon-api/CHANGELOG.mdCHANGELOGs created
sdk-libs/token-sdk/CHANGELOG.mdsdk-libs/token-pinocchio/CHANGELOG.mdsdk-libs/token-client/CHANGELOG.md(new in this update)sdk-libs/compressed-token-sdk/CHANGELOG.mdsdk-libs/event/CHANGELOG.mdsdk-libs/macros/CHANGELOG.mdsdk-libs/account/CHANGELOG.mdsdk-libs/account-pinocchio/CHANGELOG.mdsdk-libs/program-test/CHANGELOG.mdsdk-libs/instruction-decoder/CHANGELOG.mdGitHub Releases
Notes
Generated by OpenClaw release-notes automation.
Summary by CodeRabbit
New Features
Bug Fixes
Breaking Changes