docs: 📝 describe release process in CONTRIBUTING - #161
Conversation
| especially when there is human data involved and when the data is on secure | ||
| servers. | ||
|
|
||
| - Because the data is on secure servers, we can't use GitHub workflows. Which |
There was a problem hiding this comment.
| - Because the data is on secure servers, we can't use GitHub workflows. Which | |
| - Because the data is on secure servers, we can't use GitHub workflows. This |
|
|
||
| <!-- TODO: When should a "stable release" be? After all participants go through the first phases? --> | ||
|
|
||
| Breaking changes with the `<type>!` format only happens after the first stable |
There was a problem hiding this comment.
| Breaking changes with the `<type>!` format only happens after the first stable | |
| Breaking changes with the `<type>!` format only happen after the first stable |
| - Check the commit history since the last release for any releasable changes. If | ||
| no releasable changes are found, then no release is created. Otherwise, the | ||
| process continues. |
There was a problem hiding this comment.
What if there are no changes in the history but there has been a data / metadata update? We would only find that out in step 3 here.
github-project-automation
Bot
moved this from In review
to In progress
in Data development
joelostblom
left a comment
joelostblom
left a comment
There was a problem hiding this comment.
Looks good to me overall, just a small comment
| anymore. Instead, a release will only be created on a schedule (if there are | ||
| any releasable changes). | ||
|
|
||
| <!-- TODO: How often should we release? --> |
There was a problem hiding this comment.
Funnily, I implemented something similar in Altair just a few weeks ago. There, we are starting with twice a month on the 1st and 15th. Ideally I would have wanted a certain weekday, e.g. every first and third Mon of the month (so that a release doesn't happen at a time when no one is available to fix issues, but that seemed impossible to configure, at least via GitHub action's cronjob. There, I also added a step that includes human review, so a release is drafted twice a month, but then a human approves it and optionally expands on the release notes with some examples of new functionality if needed. So those are just some considerations to think about if any of them would apply here too.
3 participants
Description
This is hopefully a starting point for us to figure out how to work together and how releases should happen.
Needs a thorough review.
Checklist
just run-all