chore: bump versions (events 1.4.0, profile 1.2.0) ahead of testnet redeploy#98
Conversation
…ractmeta Version stamps had drifted and were internally inconsistent: events contractmeta said 1.2.0 while INITIAL_VERSION said 1.3.0, and neither reflected the public-surface / storage changes merged since (#86 submission cap, #88 manager two-step, #96 OpSeen namespacing). Profile was still 1.1.0 despite #95 namespacing its OpSeen. Bump both contracts coherently — INITIAL_VERSION, contractmeta, and the Cargo package version all set to: events 1.3.0 -> 1.4.0 (submission cap, manager two-step, OpSeen ns) profile 1.1.0 -> 1.2.0 (namespaced OpSeen) version()-asserting admin tests updated to match. 225 events + 66 profile tests green; make build OK (events 56,091 B, profile 15,893 B, both under the 64 KB ceiling); fmt clean.
Quota reachedYour plan allows 300 CI/CD file units per month. You've used 297 and this scan would add 9 more (total: 306). |
|
Warning Review limit reached
Next review available in: 37 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (8)
✨ 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 |
Reconciles and bumps the on-chain version stamps so the next testnet deployment reports a coherent version.
Why
The stamps had drifted and were internally inconsistent:
contractmeta=1.2.0butINITIAL_VERSION=1.3.0, and neither reflected the changes merged since 1.3.0 (fix(events): cap per-event hackathon submissions to bound storage growth #86 submission cap, fix(events): require acceptance for manager delegation (#70) #88 manager two-step, fix(events): namespace OpSeen by authorizing caller (follow-up to #68/#95) #96 OpSeen namespacing).1.1.0despite fix: non-malleable child op_id derivation and namespaced OpSeen #95 namespacing itsOpSeen.Changes
Bumped coherently across
INITIAL_VERSION,contractmeta, and the Cargo package version:version()-asserting admin tests updated to match.Verification
cargo test --workspace: 225 events + 66 profile greenmake build(stellar-cli 27): events 56,091 B, profile 15,893 B — both under the 64 KB ceilingcargo fmt --checkcleanDeploy note (context, not part of this PR)
The on-chain testnet contracts currently report 0.4.0 / 0.2.0 — they predate the credit removal and are storage-incompatible with current HEAD (dropped credit fields + sdk 23→27). So the testnet refresh should be a fresh redeploy, not an in-place H6 upgrade (which would fail to decode the old rows). This PR only prepares the version stamps; the deploy is run separately.
🤖 Generated with Claude Code