Create releasing guidelines #608
Conversation
Go API Changes# summary Inferred base version: v0.14.0 Suggested version: v0.14.1 |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #608 +/- ##
=======================================
Coverage 83.21% 83.21%
=======================================
Files 28 28
Lines 3413 3413
=======================================
Hits 2840 2840
Misses 458 458
Partials 115 115 ☔ View full report in Codecov by Sentry. |
|
|
||
| - **MAJOR**: Incompatible API changes. | ||
| - **MINOR**: Backward-compatible new features. | ||
| - **PATCH**: Backward-compatible bug fixes. |
There was a problem hiding this comment.
This is a common approach for v1+, but with current v0 we're still in officially unstable API mode (v0 is to avoid import path changes in Go module before we reach stable API). We can not use MAJOR to convey information about backwards compatibility, so a more helpful indication at the moment is to use MINOR for breaking changes and PATCH for all backwards compatible changes.
There was a problem hiding this comment.
Ok, got it, thanks. How about the below formulation then:
Current (for v0.MINOR.PATCH)
- MINOR: Incompatible API changes.
- PATCH: Backward-compatible new features and bug fixes.
After v1.X.X release
- MAJOR: Incompatible API changes.
- MINOR: Backward-compatible new features.
- PATCH: Backward-compatible bug fixes.
glibas
force-pushed
the
releasing-guide
branch
2 times, most recently
from
8ad1f45 to
de0c95d
Compare
RELEASING.md
Outdated
| 4. **Tagging:** | ||
| - Create a new annotated tag for the release. | ||
| ``` | ||
| git tag -a vMAJOR.MINOR.PATCH -m "Version MAJOR.MINOR.PATCH" | ||
| ``` | ||
|
|
||
| 5. **Push Changes:** | ||
| - Push the new tag to the GitHub repository. | ||
| ``` | ||
| git push origin vMAJOR.MINOR.PATCH | ||
| ``` | ||
|
|
||
| 6. **Create Release on GitHub:** | ||
| - Go to the [Releases] page on GitHub. | ||
| - Click on "Draft a new release." | ||
| - Tag version should be set to the newly created tag. | ||
| - Title the release using the version number (e.g., "vMAJOR.MINOR.PATCH"). | ||
| - Click 'Generate release notes' |
There was a problem hiding this comment.
I'm not sure if these 3 steps should be simplified or not, but all them can be done with just step 6 (create release and tag a version at once).
There was a problem hiding this comment.
yes, let's keep it simple, updated
glibas
force-pushed
the
releasing-guide
branch
from
de0c95d to
f3823a4
Compare
glibas
force-pushed
the
releasing-guide
branch
from
f3823a4 to
45417f5
Compare
🤔 What's changed?
Adding RELEASING guidelines.
⚡️ What's your motivation?
Was hard to figure out the release process.
🏷️ What kind of change is this?
♻️ Anything particular you want feedback on?
Nice and simple release process, just needs documenting.
📋 Checklist:
This text was originally generated from a template, then edited by hand. You can modify the template here.