Release plan

[felixfontein]

We should decide eventually on how to release this collection (w.r.t. versioning). Small collections like this one don't need a complex plan like the one for community.general and community.network (https://gist.github.com/felixfontein/2bad8517b70008ab9be90387ee4090c8). So how about the following?

1. Release 1.0.0 soon (I think Support otherName in subAltName in CSR for UTF8 strings #53 and cryptography backend: parse dirName, RID and otherName names #9 should get in in some form first, because they slightly change behavior of existing things).
2. Release minor and patch releases whenever we want (like after adding new features or fixing bugs). Since this collection is small, there's no need to fix things in advance. Just add features, and after a feature either wait a bit longer for more features/bugs, or make a release.
3. The 2.0.0 release will be without PyOpenSSL (except probably in openssl_pkcs12, since right now cryptography cannot handle PKCS12 files), and somewhen in mid 2021 (Markus pointed out that by then we can assume cryptography 2.1.4 or even newer.
4. We can obviously backport bugfixes or even features from 2.x.y to 1.X.Y if we want, i.e. we can supply the 1.X.Y series with fixes or even features for a longer time.
5. We can start planning a 3.0.0 release once we have a reason to break backwards compatibility again.

What do you think @MarkusTeufelberger @Shaps @gundalow?

We can also start with some pre-1.0.0 releases, but honestly I don't see why. New features can easily end up in post-1.0.0 releases; it's only backwards compatibility breaking (no matter how hard) changes that should go in at least for 1.0.0. And right now, the only candidates I see for that are #9 and #53 since they change the output of cryptography_decode_name.

[felixfontein]

#37 and #75 would adjust deprecations and version_added values accordingly.

[felixfontein]

Both #9 and #53 have been merged.

[gundalow]

@MarkusTeufelberger @ctrufan @puiterwijk As maintainers of community.crypto would you be able to take a look of this?

[Shaps]

This looks very reasonable to me! 👍

[felixfontein]

Also, if that's ok for everybody, we could already release 1.0.0 during the next days (i.e. directly after merging #37 and #75). Once #30 and/or #63 are done, we can do the first minor release(s) (1.1.0, and 1.2.0 if one PR needs longer than the other).

[ctrufan]

That sounds reasonable to me. Though I'll admit I haven't followed the collections migration super closely (in terms of how various modules are handling migration, especially with regards to versioning/docs).

[MarkusTeufelberger]

I wrote a little bit about maybe adding a Roadmap section to the README (so it is clear beyond some discussions in Github Issues when/how pyopenssl support will be dropped) in #75, but that's optional. I agree to the rest of the plan, looking forward to 1.0.0 landing in Ansible 2.10! :-)

[felixfontein]

@MarkusTeufelberger depending on how fast the new modules get done, there could also be 1.x.0 with x > 0 in Ansible 2.10 ;-)

About the roadmap section: good idea! I'll write up something later and probably create a new PR for that.

[felixfontein]

@ctrufan if you are interested in how it works for the large community collections, see https://github.com/ansible/community/wiki/VersioningLargeCommunityCollections

(The Ansible/RedHat controlled collections prefer to use date-based deprecation. The community working group decided against that.)

[MarkusTeufelberger]

Branching wise I think we can stay on master for now after the release and branch off a release-1.x branch in a year or so once we work on ripping out pyopenssl for good.

[felixfontein]

@MarkusTeufelberger sounds good to me! (I think I wanted to write that in the proposal, but apparently I forgot...)

[felixfontein]

Does anyone mind if we release 1.0.0 tomorrow or on Friday (once #80 is done)?

[felixfontein]

If nobody complains, I'll release 1.0.0 tomorrow afternoon.

[felixfontein]

I've just released version 1.0.0 (thanks @gundalow for helping when Zuul had problems). I've bumped the version in galaxy.yml to 1.1.0 for the next release (tenatively; we can change it to 1.0.1 if we want to release a bugfix first).

[felixfontein]

My suggestion would be to release 1.1.0 somewhen before 2020-08-18, so we can include all new features in Ansible 2.10.0 (see #99). There are currently a couple of open feature PRs, most of them ready for reviews or even for merging:

• [WIP] Add x509_certificate_revocation_info module #30 x509_certificate_revocation_info module (WIP) (I don't think this will be ready for 1.1.0)
• Add openssl_signature module #63 openssl signature modules
• Increase # of bits for random serial numbers of certificates with PyOpenSSL backend #90 improve serial numbers for openssl_certificate pyopenssl backend
• openssl_csr: add support for name constraints extension #92 openssl_csr support name constraints
• Add cipher and hash options to luks_create #97 luks_device cipher and hash option
• acme_account: add support for External Account Binding #100 acme_account external account binding

All but the first can definitely make it into 1.1.0 IMO (the first depends a bit when I find time to properly work on it again ;) ).

[felixfontein]

There's one more PR for the review list: #102

Would be happy if someone could look through the PRs listed here and above, would be nice to get them merged for 1.1.0 and thus for Ansible 2.10.

[felixfontein]

Ok, I will make a 1.1.0 release later today. @MarkusTeufelberger should I just merge #63? Also, could anyone take a look at #90 and #92? Would be nice if they could make it in as well!

[MarkusTeufelberger]

Yeah, let's just squash + merge #63. It would be great if the first commit could be preserved, since that's the initial implementation and that one is not by me.

[felixfontein]

@MarkusTeufelberger if you squash #63 down to two commits (the first, and then all others into one), we can rebase-merge it I think. Already done that.

[felixfontein]

I've triggered a 1.1.0 release (see the tag for the contents).

[felixfontein]

I just noticed we have wrong version numbers in meta/runtime.yml (#108). My suggestion is to fix this, and release a 1.1.1 version soon (before 2020-09-15, which is bugfix freeze for Ansible 2.10.0, so 1.1.1 will get included in 2.10.0). We don't have merged new features yet anyway (which would require 1.2.0).

Is that ok for everyone?

[felixfontein]

#109 is another small bugfix that could go into a 1.1.1 release.

[felixfontein]

I released 1.1.1, unfortunately without #109.

[felixfontein]

FYI: There's a security vulnerability in one module several modules in this collection, fortunately something very easy to fix. I'll push a fix and make a release next Tuesday during the early afternoon (CEST), so it gets included in the Ansible 2.10.1 release that will also be released next Tuesday (probably Tuesday night or early Wednesday morning in CEST).

[felixfontein]

1.2.0 is being released right now. Next release will be 1.3.0, date TBD.

[felixfontein]

FYI: the security issues are new to this collection (and were contained in all releases of this collection which contained the modules in question). They were not included in Ansible 2.9 and before.

[MarkusTeufelberger]

We probably should have one issue per (planned) release to link the merged PRs etc. to, this thread is starting to get cluttered a bit.

[felixfontein]

Good idea! #126 tracks 1.3.0. Should we keep this issue open for announcements, or close it (and/or replace by a new issue for release planning announcements)?

[MarkusTeufelberger]

I think we can open a new one for announcements as well as one for 2.0.0

[felixfontein]

I created an issue for 2.0.0: #128.

The new issue #127 is for release planning announcements.

I'll close this one. Everyone, please subscribe at least to #127 :)