docs: add release branching documentation#1516
docs: add release branching documentation#1516jescalada wants to merge 11 commits intofinos:mainfrom
Conversation
👷 Deploy Preview for endearing-brigadeiros-63f9d0 processing.
|
✅ Deploy Preview for endearing-brigadeiros-63f9d0 ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #1516 +/- ##
=======================================
Coverage 90.21% 90.21%
=======================================
Files 69 69
Lines 5511 5511
Branches 944 944
=======================================
Hits 4972 4972
Misses 521 521
Partials 18 18 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
kriswest
left a comment
kriswest
left a comment
There was a problem hiding this comment.
LGTM - one thought on automatically checking alignment between package.json versions and branch name.
This could/should all be added to AI steering files - if an AI can pick up that a release is being prepared it can comment on the steps to be taken, merges to be performed and potentially help execute those steps correctly.
| - `feat:` labels the PR as a feature (minor bump) | ||
| - `fix:` labels the PR as a bugfix (patch bump) | ||
| - `break:` or `feat!:` (exclamation mark suffix) labels the PR as a breaking change (major bump) | ||
| - Other prefixes map to the maintenance categories defined in `release-drafter.yml` |
There was a problem hiding this comment.
What about the ! syntax for marking breaking changes (prompts a major version bump)
|
|
||
| ### Publish to NPM | ||
|
|
||
| This workflow runs whenever you publish a GitHub release. |
There was a problem hiding this comment.
Does the workflow include any automated chacks on the version number in package.json matching the branch name? If not we should add that as it can save headaces/mistakes
|
|
||
| Just re-run the `release-drafter.yml` workflow from the related release branch. Example: If your `1.2.x` draft got overwritten, go to the [Release Drafter action page](https://github.com/finos/git-proxy/actions/workflows/release-drafter.yml), click on the run matching the latest `release/1.2` branch, and then click "Re-run all jobs". | ||
|
|
||
| ##### I published the draft release and forgot to bump the `package.json`s! |
There was a problem hiding this comment.
The release flow could automatically detect this happening (see previous comment)
2 participants
Closes #1483.
The updated workflows have been added in #1520, all documentation here reflects the changes included in that PR.
We should decide which versions will be supported (with occasional bugfixes). I thought about supporting
1.20and2.x, and then dropping support for1.20when3.0comes out, butv1has drifted so much from2.0that we'd be better off dropping support entirely to avoid all the extra work. Either way, this doc should be updated to inform users/maintainers about which GitProxy versions have active support.Notes
1.19and2.0)Would love to hear your thoughts! @finos/git-proxy-maintainers