chore: Release v1.0.0

[dknopik]

No description provided.

[claude-code-actions-sigp]

Claude finished @dknopik's task —— View job

---

Code Review Complete

Tasks

• Read all changed files to understand version updates
• Review version consistency across files
• Check for release best practices
• Verify if changelog/documentation needs updates
• Provide comprehensive review feedback

---

Review Summary

This PR bumps the version from 1.0.0-rc.1 to 1.0.0 across all relevant package manifests. The changes are mechanically correct and consistent.

Findings

✅ Code Quality & Consistency

The version bump is applied consistently across all 6 files:

• anchor/Cargo.toml: v1.0.0-rc.1 → v1.0.0
• anchor/client/Cargo.toml: v1.0.0-rc.1 → v1.0.0
• anchor/keygen/Cargo.toml: v1.0.0-rc.1 → v1.0.0
• anchor/keysplit/Cargo.toml: v1.0.0-rc.1 → v1.0.0
• anchor/common/version/src/lib.rs: Both prefix and fallback updated
• Cargo.lock: All four packages updated

⚠️ Documentation & Release Process

Missing PR Description: This PR has no description, which is problematic for a major release. Per .github/PULL_REQUEST_TEMPLATE.md, the PR should include:

• Issue Addressed: Which issue this closes (if any)
• Proposed Changes: Summary of the version bump and what it represents
• Additional Info: Release notes, breaking changes, migration guide

No CHANGELOG: The repository does not appear to maintain a CHANGELOG.md file. For a major v1.0.0 release, it would be valuable to document:

• What's included in this release
• Breaking changes from rc.1 (if any)
• Known issues or limitations
• Migration guide for users upgrading from rc.1

README Status: The README states "This client implementation is currently under active development and should not be used for production until a formal production release has been made." (lines 19-20). With v1.0.0, consider updating this notice to reflect production readiness status.

Testing & Security

• ✅ No code logic changes, only version strings
• ✅ Test regex in version/src/lib.rs:60 will correctly match the new version format
• ⚠️ No new tests needed, but consider running full test suite before tagging

Performance

No performance implications.

Recommendations

High Priority:

1. Add a meaningful PR description explaining what this release represents
2. Consider adding release notes (either in PR description or a CHANGELOG)
3. Update README.md to reflect production status if v1.0.0 signifies production readiness

Medium Priority:
4. Establish a CHANGELOG.md for future releases to track version history
5. Document any breaking changes or migration steps from rc.1 to 1.0.0

Low Priority:
6. Consider using git tags with release notes when this PR is merged

Approval Status

The technical implementation is correct and consistent. However, the lack of documentation and context makes it difficult to assess whether this release is appropriate. I recommend addressing the documentation concerns before merging.

---

[dknopik]

Consider adding release notes (either in PR description or a CHANGELOG)

Document any breaking changes or migration steps from rc.1 to 1.0.0

Changelog documentation is done via github releases.

Update README.md to reflect production status if v1.0.0 signifies production readiness

Done in #701.

[jking-aus]

lgtm - let's do it live