Plans for CI
Plans for CI
Versioning
Number: X.Y.Z
CI will automatically handle versioning, committing it directly to the main branch as part of the automated release pipeline ("Tuesday Snap"). For Patch Tuesday, it sets Z to zero and increments Y; X remains unchanged. For emergency patches, only Z is incremented, leaving the others untouched. The version is automatically incremented, pushed to main by CI, and then tagged and released.
Patch Notes
Patch notes will be auto-generated, with PRs checked against a standard format. PR titles should start with one of these words (in this order):
- Stabilised
- Added
- Updated
- Improved
- Fixed
- Removed
- Discontinued
- Miscellaneous
PR titles can be prefixed with (EXPERIMENTAL!) to exclude support obligations, or (Internal) or (Tidy) to bypass checks and not be included in the notes. This acts as a PR check and will fail if not met.
Develop vs Main
Develop is the development branch, with nothing committed directly to main except for merges and bindings regeneration. On the first Tuesday of each month, CI opens a "develop PR" to merge develop into main (so we don't forget). We can reject this PR but we must remember to open one later. Old CI branches (without an associated open PR) are removed every Monday. Each main branch commit is automatically merged onto develop, raising an issue if not possible.
Fast Track
All PRs must target develop, but with Silk.NET team approval, a PR can be targeted at main and labelled "fast-track." This requires majority maintainer approval, only for extenuating circumstances.
Emergency Patches
PRs targeting main can be marked with the "emergency-patch" label. Upon majority approval, an emergency patch PR is merged and tagged.
Bindings Regeneration
CI regenerates bindings every Thursday, opening a PR for each. It updates submodules to the latest tags unless configured differently. If regenerated bindings appear faulty, a maintainer can manually handle it by closing the PR.
8 Replies
.
@Maintainer PTAL
clarification on fast-track: this is basically if we have something cooking on develop and want to squeeze a fix in before the tuesday snap
https://discord.com/channels/521092042781229087/587346162802229298/1158298803204526110
@kaijellinghaus wdym reinvent the wheel? It’s just a PR check? And the commit conventions is literally just so that the release notes look good when generating them.
most of this is done by conventional commits already, no?
Yes but following a different convention
we could use conventional commits but there’s then a chance that the release notes do not make grammatical sense
and that’s just the commit thing, conventional commits won’t do the branch management for us
fair I suppose
anyways
that really wasn't the bit i was hoping you'd focus on haha
are you happy with all the other stuff?
oh I thought we had discussed that ahead of time - I'm happy with the change in general, as long as the automation somewhat works
IMO this is more work in general, but if it's automated I think it makes a lot of sense
which is why I brought up that there's at least adjacent existing tools, so maybe we don't need to produce as much other code
yeah that’s the goal, I basically want is to always be shipping updates with at the very least regenerated bindings
the binding automation works today but keeps falling over when the branch isn’t deleted
i dont have any problems with this