Open felixfontein opened 4 years ago
FYI: I'm currently working on generalizing Ansible's internal changelog generator to collections (https://github.com/felixfontein/ansible-changelog/) and ACD, and here's the current changelog for 1.0.0 (as "the next release after Ansible 2.9"): https://github.com/felixfontein/community.crypto/tree/changelog-1.0/changelogs
In particular, here's the generated ReST file: https://github.com/felixfontein/community.crypto/blob/changelog-1.0/changelogs/CHANGELOG-v1.rst
And here's the generated YAML file (https://github.com/ansible-collections/overview/issues/18#issuecomment-613036927) which is the changelog in machine-readable format (will be used for creating ACD changelog): https://github.com/felixfontein/community.crypto/blob/changelog-1.0/changelogs/changelog.yaml
I never followed up to the last comment: the combined changelog for Ansible 2.10 is here: https://github.com/ansible-community/ansible-build-data/blob/main/2.10/CHANGELOG-v2.10.rst
Anyway, if you haven't done so, check out #74 (release plan) and subscribe to it to get updated on discussions/information about new releases. Finally, there are two bugfix PRs which could use a review: #108 and #109. With these included, I propose a 1.1.1 release soon which would get included in Ansible 2.10.0.
Please note that we now have an issue for release planning (and release) announcements: #127
We also have issues for planning the next release (1.3.0): #126, and for planning the 2.0.0 release: #128
Beginning of December, Ansible and all collections using Shippable (i.e. also us) are migrating from Shippable to Azure Pipelines (ansible-collections/overview#124). community.crypto will be one of the first collections to migrate. This mainly means that CI might not be perfectly working during that time; since Shippable will only be removed after AZP works, it shouldn't be too bad.
@Spredzy @xyon @Shaps @MarkusTeufelberger @puiterwijk @resmo if anyone of you has a bit of time, I would be glad if you could take a look at some of my open PRs: #150, #163, #166, #167
The last Ansible 2.10.x release will probably happen next Tuesday (January 26th), so it would be great if we could make a release before that. Would be nice if at least some of the PRs could make it in!
I started writing some guides for creating certificates (for the moment, using the selfsigned and ownca providers) at https://github.com/ansible-collections/community.crypto/pull/237. Any feedback/reviews/... welcome!
We're happy to announce that the registration (free) for the Ansible Contributor Summit is open.
Which day should you attend?
Refer to the registration page for details.
See you at the summit!
Reminder - AnsibleFest and Ansible Contributor Summit are 1 week away!
In case you missed it, we will also be having a Hackathon throughout the entire Ansible Contributor Summit and AnsibleFest. This is a great opportunity to collaborate in real time with other members of the Ansible Community!
For more info and the latest updates, please see the Ansible Contributor Summit 2021.09 HackMD.
The discussion on whether to add a replacement for the assertonly
provider is still not concluded. I've added my (current) opinion to it in #76, and I would be really glad if more people could pitch in, whether we still need a verification module like the assertonly
provider or whether other mechanics (using the _info
module, idempotency of other modules, ...) are enough.
I suggest we drop support for Ansible 2.9 and ansible-base 2.10 in the next major release. Both will be EOL in May 2022 anyway, and some versions of both cause problems (see https://github.com/ansible-collections/community.crypto/pull/371). I think we should also have some policy when we drop support for ansible-core versions, and/or stop testing against them. I would suggest to strip EOL'ed ansible-core versions to minimal testing in CI (also so our CI matrix does not grow unbounded) and drop support for all EOL'ed ansible-core versions (and the ones which will EOL in the next 1-2 months) on every major release.
Does that sound reasonable? Any feedback, other ideas, ...?
(See also https://github.com/ansible-community/community-topics/issues/50 for a similar discussion for community.general and community.network.)
Right now we're using issues to track minor releases. @briantist suggested to use milestones here. I think that definitely makes sense for minor releases; for major ones I'd still have an issue (next to a milestone). What do you think?
If anyone is interested in Execution Environments, please take a look here: https://github.com/ansible-collections/community.crypto/pull/440#issuecomment-1100605304
Welcome to the
community.crypto
pinboard! Please subscribe if you are interested in general topics oncommunity.crypto
!Continues ansible/community#444