Proposed branching/release process #672
Conversation
| 1. Work on `main` branch | ||
| 2. General PR's are submitted against the `main` branch | ||
|
|
||
| When it is time to make a new release, we create a `x.y-stable` branch (e.g `0.9-stable`) from `main` |
There was a problem hiding this comment.
Should there be a separate list for how to perform patch releases on the stable branch - and how to keep the changelog in sync with main?
|
|
||
| All further PR's are still done to `main` | ||
|
|
||
| 1. If they are applicable to previous release (e.g bugfixes or non-breaking changes), they are cherry-picked back to the applicable `stable` branch(es) |
There was a problem hiding this comment.
How do you want this to happen? Should this be discussed/described in a PR beforehand? Then, should a maintainer perform the cherry-pick as soon as a PR is merged so that it is not forgotten about?
Or should this be a more dynamic process, where a maintainer (in an issue/discussion) at some point decides pick/backport a list of merged PRs and publish a patch release?
It depends on the kind and volume of changes/contributions a repository receives, keeping up with cherry-picks might turn out to be a lot of work but also prevents the stable branch from lagging behind and turning into a gigantic pile of work when it comes to making a patch release.
Perhaps a more rigorous maintenance plan needs to be put in place (how often to allow breaking releases, how long to support how many older stable versions, whether to at least publish a patch release with accumulated fixes/additions right before doing the next breaking release, etc.), but that can also form over time pending how this release process pans out (again: depends on how many breaking changes vs purely additions/bugfixes this repo receives).
There was a problem hiding this comment.
These are good points, but I suspect we should come back to this later in the interests of progress
For now I think the PR's would just go to the development branch, and if required be backported to stable by whoever merges them (e.g click merge, decide if it needs backported)
Once we are back to a less "abandonded-looking" development cycle, we should definitely discuss this further!
Co-authored-by: Marijn Suijten <[email protected]>
|
@dbr Where are we at on this? I'd like to start using a newer |
|
@dbr @thomcc @sanbox-irl another friendly nudge 😉 |
|
@dbr @thomcc @sanbox-irl once again? What's the hold up for fleshing out the release process and finally bringing this update out to users? |
Create tags and push them, create release, close tickets
|
Thanks for the gentle poking @MarijnS95 - sorry for the absense, no specific reason for the delay, just my attention has been dragged to work and house things! Shall merge this as-is - shall tweak it when I actually go through the release process, and as mentioned in comment above we should definitely revisit some aspects of this later I'll aim to get a release out in teh next few days - the only blocking thing remaining is.. I don't have access to the crates.io package (never noticed when I was added as a maintainer here, as sandbox has performed the last few releases!). I'll email him about this now |
|
@dbr thanks, glad to see this being picked back up! |
As per my intepretation of @MarijnS95 's comment #665 (comment)
Goal being simple simple and easy to stick with. I'd like to expand the doc with exact step-by-step commands to make things trivial to follow along in future, but best to do that as part of releasing v0.9.0
@thomcc @sanbox-irl - any thoughts/opinions/desires-to-switch-back-to-SVN? 😛