Create a policy for hotfix/bugfix ansible releases
gotmax23 opened this issue · 6 comments
Summary
Currently, we preform releases every three weeks following ansible-core releases. Occasionally (e.g. ansible-community/ansible-build-data#232, ansible-community/ansible-build-data#114), there may be a reason to cut a bugfix release. We should consider creating a policy on when to preform interim bugfix releases and add documentation for how to cut a hotfix/bugfix release in ansible-build-data (ansible-community/ansible-build-data#221 tracks release documentation efforts).
It's every four weeks, not every three.
In the past we did some bugfix releases:
- 5.7.4 (May 2022)
- 5.0.1 (December 2021)
- 2.10.3 (one day after 2.10.2) - note that we did use a different version scheme back then
5.7.1: "This is a hotfix release to ansible 5.7.0 in order to roll back the version of fortinet.fortios to 2.1.4 from 2.1.5 to address a syntax error pending a new release of the collection."
5.0.1: "Ansible 5.0.1 raises the python requirement from >=2.7 to >=3.8 in order to match ansible-core. The content of 5.0.1 is otherwise identical to 5.0.0." - we even had to remove 5.0.0 to make some old pip versions happy.
2.10.3: "Yesterday's release of Ansible-2.10.2 contained some output from running tests which amounted to a 30% increase in the size of the Ansible tarball. The size ended up doubling the time necessary to install ansible using pip. The Ansible-2.10.3 release removes the test output to bring the size back down to a more normal level. Other than that, it should be the same as the 2.10.2 release."
So far, all bugfix releases for Ansible (after 2.9) were about packaging issues. Security issues were fixed in regular 'minor' releases. (This is also what ansible-core does.) But then, we also were not aware of a serious (enough) security issue fixed in a collection long before the next Ansible release.
@samccann suggested:
I'd say a secruity issue gets fixed, anything else is up to the discretion of the release manager, with the option to raise it to the steering committeee if the user feels it needs to override the release manager
and there was some agreement about that policy in the meeting.
Later, it was suggested to open up this decision to all of the 'release team' and ansible-build-data committers
Regarding security fixes, I think it depends on how critical they are (and how critical the underlying issue is). Not every security fix in a contained collection does need to trigger a new bugfix release, that would just be excessive.
Having a consensus between a few folks of the release team and the ansible-build-data committers sounds like a good idea as a criterium for whether to make a release or not.
@gotmax23 Please close this issue if done, or open a new forum topic and then close the issue with a pointer to the new discussion: Community-topics: Archiving the repo
as @gotmax23 is notified, let's close it, thanks everyone!