Add versions to requirements.yml examples

[aharden]

In a production Ansible configuration, it should be a best practice to provide desired versions of Galaxy roles that are to be downloaded to support the playbooks. I recommend adding versions to the roles in the requirements.yml files in the examples as you get closer to the 1.0 release.

[geerlingguy]

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.

[aharden]

@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.

[geerlingguy]

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