Closed iloving closed 3 years ago
jctanner
commented
5 years ago Not saying there aren't any, but can you include examples of things that have broken? Sometimes it's honest mistakes and we weren't aware of edge cases and no tests were written for them.
bcoca
commented
5 years ago sometimes its due to a security vulnerability, in which case i would advice strongly against keeping the 'older version'.
iloving
commented
5 years ago True. But that sort of fix would be included in a patch release, not a major revision. It makes sense to keep patch releases within the same major release version.
ie:
-You have ansible2.6 installed.
-You run yum update (or apt, or pip, or whatever)
-Your package is still ansible2.6 but the actual version is 2.6.1 or some such.
Also, just to be clear, when I use the term 'broken', I mean: "The playbook worked before I updated, and now it doesn't." It could have been due to a mistake, but more likely it was an explicit change in Ansible.
A specific example is what happened from 2.4 to 2.5. Variable handling was fundamentally changed in 2.5, causing any playbook that passed variables between different includes to break in a very non-obvious way. People who were caught off guard had to contend with all sorts of crazy problems, including but not limited to, their playbook commands running on the wrong different machine.
More generally, there is a porting document for every release. Anything that goes into that porting document that is a changed or removed behaviour, is nothing less than a backward-compatibility breaking change. It doesn't matter how small or big that change is. It still requires people to revisit their playbooks.
It is unreasonable to expect people to have to drop what they're doing and start digging through playbooks every time there is a new release. Currently, people are forced to take steps to regain control of the release process, as I described in the issue.
bcoca
commented
3 years ago The ansible-core follows that x.y releases are feature releases and might have backwards incompatible changes (via 4 release deprecation cycle). The x.y.z releases are bugfixes and any backwards incompatible change is either due to the behavior being a bug or unintended. As such I consider we already follow this proposal (distro packages know our release numbering and also act accordingly) so I'm going to close as 'completed'
Proposal: Major releases should be packaged as separate versions
Author: Ilsa Loving <@iloving> IRC: n/a
Date: 2018-08-23
Motivation
The frustration of having to debug all existing playbooks upon every release.
Problems
What problems exist that this proposal will solve?
Upon every major release of Ansible, there are major changes that break backwards compatibility and force people to review/revise all of their existing playbooks. That means that for every additional playbook you have, you have increased your maintenance load by that amount.
Ansible is currently distributed as a single package whose version is continually incremented, which means there is no distinction between each release.
The two behaviors combined is forcing users to take sometimes extreme measures to help reduce the maintenance burder. This varies from version locking, implementing continuous delivery processes, to the most extreme: The Ansible Silo project that dockerizes every single version of Ansible.
Solution proposal
Ansible should be packaged similar to how Java does it. Every major release has the version included as part of the package (ie: ansible2.4 instead of just ansible)
Dependencies can be version locked to the specified Ansible release.
The benefits are thus: -It is not long necessary to implement extreme measures to manage the maintenance burden -Upgrades are safer to perform because there is no fear that your playbooks will suddenly and unexpectedly stop working (Or at least, much less likely) -A User can easily switch between different versions of ansible via /etc/alternatives, environment variables, whathaveyou. For example, the user can use alternatives to set a default version, but other versions would also still be accessible.
Dependencies (optional)
Explain any dependencies. This section is optional but could be helpful. n/a
Testing (optional)
Does / should this require testing, and if so, how? Describe here. This section is optional but could be helpful. Verify that each simultaneous version installed is able to run successfully.
Documentation (optional)
Does / should this require documentation? If so, describe here. This section is optional but could be helpful. Instructions for incorporating ansible into the alternatives subsystem would be helpful, as well as how to execute an explicit version.
Anything else?
If you'd like to add anything else beyond the above required and optional sections, you are welcome to do so.