Automation For Release Process
During discussion of !147 (merged) , we veered into a discussion of how to automate this work to make life better.
This is an issue to discuss how we can iterate toward that process. The original discussion is below.
Should we add when to perform this action?
That is a good question; it looks like the typical behavior has been when a new feature is added or several at once if they all land on the same day.
@ibaum and @balasankarc - what are your guidelines for how often to cut a release?
Historically it has basically been when someone asks for a release. A couple of times there has been other MRs in the pipeline, so we've waited for those before doing a release.
So maybe start with a new release is planned when an MR author requests one? Maybe have a dedicated label or something?
I see two angles here:
- often times a release is meant to unblock some specific chain of work so it's better to just cut the release as needed
- updating the version frequently runs up the version numbers and may place a burden on maintainers
Unless we feel that cutting a release when someone asks has become too onerous/frequent, the process isn't really broken. What would be our compelling reason change it?
"When someone asks for a release", or "When there is an associated MR in any other project that waits for this one (to be specified in MR description)" has been my usecases so far.
I think I had started a branch where I add a manual job at the end of the master pipeline to tag a new release, that can be just played. Something that checks if a tag exists for this SHA and creates if there isn't one.
So what about a scheduled job that, every week on Tuesday, cuts a release if there's no tag for the SHA and then maintainers can cut one immediately by manually running it if it's needed for unblocking?
I think we're veering off an interative course here. If folks feel the need for automating when a release is cut, or automating the process, we should follow up in a separate issue/mr. This is a useful MR that documents the current state of things, I'd advocate for merging.