feat: Smart version bumps based on PR labels

[0xvasanth]

Summary

Enhanced the version-bump workflow to intelligently determine version bump type based on PR labels.

Changes

• Label-based version bumps:
  • PRs with major label → major version bump
  • PRs with minor label → minor version bump
  • PRs without labels → patch version bump (default)
• Version check: Skip publishing if version already exists on crates.io
• Enhanced release notes: Include version bump type in GitHub releases
• Created labels: Added major and minor labels to repository

How it works

1. Workflow checks PR labels on merge
2. Determines appropriate version bump type
3. Updates version and publishes only if new
4. Creates GitHub release with bump type information

Testing

• Workflow syntax validated
• Pre-commit hooks pass
• Labels created successfully

This enables proper semantic versioning based on the nature of changes in each PR.

[Copilot]

Pull Request Overview

This PR implements smart version bumping functionality that automatically determines the semantic version bump type (major, minor, or patch) based on PR labels. The workflow now checks for specific labels on merged PRs and applies the appropriate version increment.

Key changes:

• Added label-based logic to determine version bump type with fallback to patch
• Implemented version existence check to prevent duplicate publishing to crates.io
• Enhanced release notes to display the version bump type and publication status

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[Copilot]

The version check logic is flawed. The cargo search command returns results in the format gonfig = \"latest_version\" but this checks for an exact match with the new version. If the new version is newer than what's published, this grep will fail even when the version doesn't exist on crates.io.

Suggested change

	if cargo search gonfig --limit 1 | grep -q "gonfig = \"${{ env.new_version }}\""; then
	if curl -s "https://crates.io/api/v1/crates/gonfig" | jq -e '.versions[].num == "${{ env.new_version }}"' > /dev/null; then

[Copilot]

The upper filter is not a valid GitHub Actions expression filter. This will cause a workflow syntax error. Use {{ steps.version_type.outputs.bump_type }} and handle case conversion in the shell script if needed.

Suggested change

	**Version Bump:** ${{ steps.version_type.outputs.bump_type | upper }}
	**Version Bump:** ${{ steps.version_type.outputs.bump_type }}

[claude]

Code Review for PR #6: Smart version bumps based on PR labels

🎯 Overall Assessment

This PR introduces an intelligent version bumping mechanism based on PR labels, which is a solid improvement to the CI/CD pipeline. The implementation enhances the semantic versioning workflow and adds important safeguards.

✅ Strengths

1. Smart Version Bumping: The label-based approach (major/minor/patch) provides excellent control over semantic versioning, making it easier for maintainers to manage releases appropriately.

2. Duplicate Prevention: The crates.io version check prevents redundant publishes, which is crucial for avoiding failures and maintaining clean release history.

3. Enhanced Release Notes: Including the bump type in GitHub releases improves transparency and helps users understand the scope of changes.

4. Good Defaults: Defaulting to patch bumps when no labels are present follows the principle of least surprise.

⚠️ Potential Issues & Recommendations

1. Label Detection Logic

   • Issue: The current substring matching ("major" and "minor") could match unintended labels (e.g., "non-major-change" would trigger a major bump).
   • Recommendation: Use exact label matching or word boundaries:

   if echo " $LABELS " | grep -qw "major"; then

2. Version Check Race Condition

   • Issue: The crates.io check might have a delay between query and publish, potentially causing race conditions if multiple workflows run simultaneously.
   • Recommendation: Consider using cargo's built-in --dry-run flag first or implement a retry mechanism.

3. Error Handling

   • Issue: No explicit error handling if cargo set-version fails.
   • Recommendation: Add set -e at the beginning of shell scripts or check exit codes explicitly.

4. Missing Documentation

   • Issue: The workflow doesn't document which labels trigger which bump types.
   • Recommendation: Add comments in the workflow file or update repository documentation to explain the labeling strategy.

🔒 Security Considerations

• ✅ Good: Uses GitHub's built-in label context rather than parsing potentially untrusted input
• ✅ Good: Properly uses GITHUB_OUTPUT instead of deprecated set-output commands
• ⚠️ Consider: The workflow has broad permissions. Consider restricting to minimal required permissions using:

  permissions:
    contents: write
    packages: write

🚀 Performance Considerations

• The cargo search command for version checking adds network latency. Consider caching or using the crates.io API directly for faster lookups.
• Multiple cargo metadata calls could be consolidated into a single call with the output reused.

🧪 Test Coverage

• ✅ The PR mentions workflow syntax validation and pre-commit hooks
• ⚠️ Missing: No apparent integration tests for the label detection logic
• Recommendation: Consider adding a dry-run mode or test workflow that validates the version bump logic without actually publishing

📝 Additional Suggestions

1. Label Validation: Consider failing fast if conflicting labels (both "major" and "minor") are present.

2. Changelog Integration: Future enhancement could automatically update a CHANGELOG.md file based on the bump type.

3. Version Pinning: The workflow uses cargo-edit without version pinning. Consider pinning to a specific version for reproducibility.

4. Rollback Strategy: Document what happens if a version bump needs to be reverted.

✨ Conclusion

This is a well-thought-out enhancement that significantly improves the release process. The implementation is clean and follows good practices. Addressing the label matching precision and adding better error handling would make this production-ready. Great work on automating semantic versioning! 🎉