Change release workflow to ZeroVer and encapsulate version info#48
Change release workflow to ZeroVer and encapsulate version info#48
Conversation
ff50a42 to
b70ef1d
Compare
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review infoConfiguration used: Repository UI (base), Organization UI (inherited) Review profile: CHILL Plan: Pro 📒 Files selected for processing (8)
📝 WalkthroughWalkthroughVersion management refactored from CalVer to semantic versioning (v0.x.y format). Version variables moved from cmd package to internal/version package with exported getter functions. CI/CD workflows updated to validate and generate new tag format. Build tooling and all code references updated accordingly. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
🚥 Pre-merge checks | ✅ 2✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Motivation
Going with ZeroVer first keeps our options open. We can still decide later if we want CalVer or a proper SemVer 1.0.0 release. The March release doesn't need to be
0.1.0either. It's fine if we end up at0.6.0after some internal iterations. We won't focus on the version number anyway. See PRO-220.Also, it turns out tags pushed with
GITHUB_TOKENdon't trigger other workflows. That's why CI wasn't running automatically after creating a release tag. UsingPRO_ACCESS_TOKENfixes this. GitHub docsChanges
v0.minor.patch)internal/versionpackageTests
Verified goreleaser ldflags locally: