Document release process: pre-releases, rollbacks, and changelog

[thatsjet]

Summary

Document the release lifecycle for future contributors and maintainers.

Instructions

Add release process section to README.md or create RELEASING.md

Cover:

1. Pre-release versions

• Format: v1.0.0-rc.1, v1.0.0-beta.1
• PyPI: supports pre-release markers (PEP 440): 1.0.0rc1
• npm: supports semver pre-release: 1.0.0-rc.1
• Maven Central: use -SNAPSHOT during development, release candidates as 1.0.0-RC1
• Go: supports semver pre-release tags: golang/v1.0.0-rc.1

2. Rollback strategy

• PyPI: Can yank (hide from pip install) but not delete. Yank via pip install won't resolve yanked versions. Use pypi.org web UI or twine to yank.
• npm: Can npm unpublish within 72 hours of publish. After that, can only deprecate.
• Maven Central: Artifacts are permanent. Cannot delete or replace. Only option is to publish a new version with the fix.
• Go: Tags can be retracted via retract directive in go.mod. Doesn't delete but warns consumers.

3. Changelog generation

• Use git log --oneline v1.0.0..v1.1.0 for manual changelogs
• Consider GitHub's auto-generated release notes (enabled by default in release workflow)
• Optionally adopt Conventional Commits for structured changelogs in the future

Verification

• Documentation exists and covers all 3 topics
• Each registry's specific behavior is documented
• A contributor could follow the docs to cut a release