New Release Workflow Policy
This is an issue to keep track of our plan to change our release workflow for O4b.
I plan to write a proposal for a new policy, which I'll add to this issue. Currently, we've discussed this on at least two calls.
The motivation to change the release workflow is to support expedited releases that only contain emergency bug fixes (i.e. they are not just a snapshot of main
). We had to do a release like this for v2.1.9 (#732 (closed)) and it was not a smooth process, plus it introduced a release that lives on a different branch instead of on main
like all of our previous releases.
- 23-11-21 LL technical call, Duncan shared a proposal https://git.ligo.org/emfollow/gwcelery/-/wikis/telcons/2023-11-21
- Presentation by Duncan Macleod in agenda
- There are no minutes, but just as a note: The group seemed to like Duncan's proposal in general, with the caveat that we don't change our current model of aiming to always turn
main
into a release. Duncan's proposed workflow allows for a more flexible use of main where feature development can continue on main without guarantee of going into the next release, but our project is not large enough in scope to need that functionality and we don't have enough contributors to support that workflow model anyway. We also would not change our policy of supporting only the latest release (i.e. we will not in general backport bug fixes or security patches to old releases).
- There are no minutes, but just as a note: The group seemed to like Duncan's proposal in general, with the caveat that we don't change our current model of aiming to always turn
- Presentation by Duncan Macleod in agenda
- 23-11-28 LL Technical Call agenda
- Agenda contains a proposal from Roberto about implementing Duncan's suggestion.