Release: update version to v0

[cawpea]

No description provided.

[github-actions]

PR Review: Release Configuration Update to v0

Overview

This PR updates the semantic-release configuration to maintain the package at version 0.x while establishing proper semantic versioning rules. The changes revert the version from 1.0.0 back to 0.1.0 and configure semantic-release to keep breaking changes as minor version bumps (keeping v0.x.x).

---

✅ Strengths

1. Well-Aligned Configuration: The semantic-release rules correctly implement the 0.x versioning strategy where breaking changes trigger minor bumps instead of major bumps.

2. Clear Intent: The changes clearly communicate that this project is still in initial development phase (0.x.x).

3. Proper Cleanup: The CHANGELOG.md was appropriately cleaned up to remove the premature 1.0.0 release entry.

---

🔍 Code Quality & Best Practices

Configuration Structure (.releaserc.json:4-22)

• ✅ The release rules are comprehensive and cover all conventional commit types
• ✅ Properly disables releases for non-production changes (docs, style, refactor, test, build, ci, chore)
• ✅ Follows semantic-release plugin best practices

Versioning Alignment

• ✅ package.json, package-lock.json, and CHANGELOG.md are all consistently updated
• ✅ Changes align with the documented git conventions in the repository

---

🤔 Potential Issues & Concerns

Critical: Alignment with Documentation

The git-conventions.md file states that feat triggers a MINOR (1.x.0) bump and fix triggers a PATCH (1.0.x). However, the new .releaserc.json configuration maps:

• Breaking changes → minor (0.x.0)
• feat → minor (0.x.0)
• fix → patch (0.0.x)

While this is the correct behavior for 0.x versions (as per semantic versioning convention), there's a documentation gap:

Recommendation: Update docs/development/git-conventions.md to clarify that:

1. During 0.x development, breaking changes and features bump the minor version
2. Once the project reaches 1.0.0, the standard semver rules apply
3. Or add a note explaining the versioning strategy for pre-1.0 releases

Minor: Missing Context in PR Description

The PR has an empty body. Consider adding:

• Why the project is staying at 0.x
• What criteria need to be met before releasing 1.0.0
• Link to any related issues/discussions

---

🚀 Performance & Security

• ✅ No performance concerns (configuration change only)
• ✅ No security concerns
• ✅ No runtime code affected

---

🧪 Test Coverage

• ✅ No new tests needed (configuration change only)
• ✅ Existing tests should continue to pass
• Recommendation: Consider adding a CI check to validate that package.json version matches the intended versioning scheme (stays 0.x.x)

---

📚 Documentation Update Needs

Required:

1. docs/development/git-conventions.md - Add section explaining 0.x versioning strategy and how it differs from post-1.0 versioning

Optional:
2. README.md - Consider adding a badge or note indicating the project is in initial development (0.x)
3. PR description - Add context about the versioning decision

---

✨ Summary

This is a solid configuration change that properly implements semantic versioning for a pre-1.0 project. The main action item is updating the documentation to reflect the 0.x versioning strategy to avoid confusion.

Verdict: Approve with minor documentation updates recommended.

---

Suggested Next Steps:

1. Update git-conventions.md to document 0.x versioning behavior
2. Add context to PR description
3. Consider documenting when/why the project will bump to 1.0.0

[github-actions]

🎉 This PR is included in version 0.2.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀