Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: migrate to GitHub's automatic release notes #27

Closed
4 tasks
ichoosetoaccept opened this issue Dec 15, 2024 · 2 comments · Fixed by #28, #29, #30 or #36
Closed
4 tasks

refactor: migrate to GitHub's automatic release notes #27

ichoosetoaccept opened this issue Dec 15, 2024 · 2 comments · Fixed by #28, #29, #30 or #36

Comments

@ichoosetoaccept
Copy link
Owner

Current Setup

  • Using custom auto-release.yml workflow for:
    • Version bumping (YYYY.MM.PATCH format)
    • Changelog generation
    • Release PR creation
  • Using auto-changelog for CHANGELOG.md generation
  • Pre-push husky hook for changelog updates

Proposed Changes

  1. Migrate to GitHub's native release notes system
  2. Remove auto-release.yml workflow
  3. Update release.yml configuration for docs-focused categories:
    • Documentation Updates 📚
    • Community Resources 🤝
    • Repository Improvements 🛠
    • Other Changes

Impact Analysis

Version Management

  • Need to ensure GitHub's release system supports our YYYY.MM.PATCH versioning
  • Verify if we can maintain Keep a Changelog philosophy

Changelog Management

  • Currently have dual sources of truth:
    1. CHANGELOG.md (via auto-changelog)
    2. GitHub Release Notes
  • Need to decide on single source of truth

Required Updates

  1. Update CONTRIBUTING.md with new release process
  2. Review and update husky hooks
  3. Update PR templates for proper labeling

Questions to Address

  1. Can GitHub Releases replace our current versioning system?
  2. Should we keep auto-changelog for CHANGELOG.md or rely solely on GitHub Releases?
  3. What changes are needed in our PR workflow to ensure proper categorization?

Success Criteria

  • Simplified release process
  • Maintained or improved changelog quality
  • Clear documentation for contributors
  • No loss of current automation benefits
@ichoosetoaccept
Copy link
Owner Author

Update on the release categories:

We've already simplified the release categories to a more maintainable structure:

  • 📚 Content: For content-related changes
  • 🛠 Maintenance: For meta/maintenance changes
  • Other Changes: For everything else

This simpler structure is working well and makes it easier for contributors to categorize their changes. Suggesting we keep this structure instead of the previously proposed categories.

Copy link

🎉 This issue has been resolved in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment