Open gundalow opened 4 years ago
The deprecation example you give is deprecating a whole module. There are also cases where we want to deprecate options/defaults. It might be worth adding a something similar for options.
I still think this is a useful thing. I know it can't ever do everything. I feel like this plus linter would be good for Devtools, thiugh needs to be part of a wider plan, rather than piecemeal.
Proposal:
Author: John Barker <@gundalow>
Date: 2019-11-04
Motivation
Currently, each version of Ansible includes a Porting Guide containing manual steps that users are required to look at and manually update their Playbooks, or just keep on running
ansible-playbook
till the deprecation notices go away.A Porting Guide
This can include things like:
foo
tobar
foo
tofar
Size of Porting Guide
Rounded number of lines
porting_guide_2.x.rst
:Partly the size is increasing as we get better at including things in the porting guide, partly as we are forcing users to change more per release.
This could be done in a way so Porting Guide fragments could be contained in Collections and pulled together to go alongside Ansible releases.
Solution proposal
Create a tool to "upgrade" Playbooks from one version of Ansible to the next, similar to:
2to3
Some of this could be automated, ie:
porting_data_2.9.yml
(Steps needed to go from Ansible 2.8 to Ansible 2.9)Example upgrade
New tool
ansible-update
(or could be related toansible-lint
)Think it terms of
Generating Docs
This, along with https://github.com/ansible/ansible/blob/816e194e375913537b31c2c8e2bd5baa6fdfb308/lib/ansible/modules/network/vyos/_vyos_interface.py#L36-L39 could be used to generate the Porting Guides.
Rather than a list, this could be used to generate a table like debops do, thanks drybjed for the suggestion.
Dependencies (optional)
Explain any dependencies. This section is optional but could be helpful.
Testing (optional)
Documentation (optional)
Anything else?