Add versions to requirements.yml examples about ansible-for-kubernetes HOT 3 OPEN

@geerlingguy I think a good compromise might be to explicitly put 'version: latest' in the examples and explain in the text that production processes should be locked into specific versions to avoid accidental breakage.

from ansible-for-kubernetes.

@aharden Agreed. I think at a minimum I'll do that, and put a 'Warning' aside. Thanks for the suggestion!

from ansible-for-kubernetes.

I have gone both ways on this, for the book examples:

• On the one hand, as you mention, for production use, you should always use specific versions (tags), ideally immutable versions (though you can't get that with Galaxy roles, only collections today).
• On the other hand, it has two downsides specific to the book:
  1. It makes maintenance more difficult, as in addition to updating about 15 other parts of the book every few months, I'll need to spend a few hours updating all the role versions every time I update the book.
  2. This book's repo actually has a number of end-to-end functional tests for my roles that I might not cover in the role's repo CI itself (whether that's a flaw in my test methodology or not, we can debate elsewhere ;). So if I keep them on 'latest', I can find flaws (and avoid bumping into deprecated usages after new Ansible releases) more quickly and easily through the repo's CI builds.

That said, it would be kind of nice if Ansible let me say 'override versions and use latest' using the ansible-galaxy cli. I could also include two versions of the requirements.yml files, one with and one without (for CI), but that still requires more maintenance.

from ansible-for-kubernetes.