Issue #40: Add changelog and fragments and document new changelog process.

[geerlingguy]

Closes #40.

[codecov]

Codecov Report

Merging #131 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #131   +/-   ##
=======================================
  Coverage   42.56%   42.56%           
=======================================
  Files           3        3           
  Lines         545      545           
  Branches      110      110           
=======================================
  Hits          232      232           
  Misses        270      270           
  Partials       43       43           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e6773fd...8674a44. Read the comment docs.

[geerlingguy]

Well that's annoying...

Command "ansible-doc -t connection community.kubernetes.kubectl" returned exit status 0.
>>> Standard Error
[WARNING]: Collection community.kubernetes does not support Ansible version
2.11.0.dev0

[felixfontein]

Why not simply having requires_ansible: '>=2.9?

[felixfontein]

Looks good from everything I can judge. I'm not sure whether listing new modules/plugins also in the major_changes section is a good idea, but that's something you (as in c.k maintainers) have to decide for yourself.

[fabianvf]

It is a little odd to have the new modules repeated in New Modules and Major Changes, but just a little

[geerlingguy]

@fabianvf - Yeah... the thing is if I don't do that there's no changelog fragment and link back to the issue where the new module was added.

[geerlingguy]

I just realized the issue ID doesn't make its way into the changelog at all... @fabianvf - should we manually drop a reference into each of the fragments too? I like being able to click through from GitHub's rendered page to an issue if I want to check out the issue/PR that introduced the change.

[felixfontein]

@geerlingguy the recommendation in https://docs.ansible.com/ansible/devel/community/development_process.html#changelogs-how-to is to include a link to the issue and/or PR in the fragment itself. That way you can also click on it when the community.kubernetes changelog is viewed as a subset of the Ansible changelog.

[fabianvf]

@geerlingguy yeah I definitely like the PR reference in the changelog. On the operator-sdk we wrote a tool that combines fragments and finds the PR# for the change based on the PR referenced in the commit that merged the changelog fragment
edit: This is the project: https://github.com/operator-framework/operator-sdk/tree/master/hack/generate/changelog

I'd be happy to integrate it into this project if we wanted to (in the long-run we plan to split it out to its own project at which point we could just pull in the binary)

[geerlingguy]

@fabianvf - I think for now the idea is all the ACD/pip install ansible collections will build changelogs using antisbull so the fragments are compatible with the upstream build.

I've updated all the fragments to include PR/issue links, and regenerated the changelog. It seems everything's now ready to go!

Note: I didn't add any fragments for new issues/PRs merged since 0.11.0. That will (for now at least) be the responsibility of whomever tags the next release.