0.12.0 release planning

[cpu]

Let's gather some context for release planning since there have been a few requests.

Some items that are close to being done that I think we should block on:

• Add PreSpecified(Vec<u8>) option to KeyIdMethod. #197
• Add external types CI check + config #183
• A functional rustls-cert-gen with basic parameters. #190 - requires additional maintainer review.
• Refactor KeyPair constructor #170 - requires update for review feedback. edit: consensus here is to skip this one.

Some items that will require a major version increase that are not as close to being completed:

• Enforce extension uniqueness #155
• Allow CSR parsing to handle custom extensions #150
• X509v3 extensions from certificate not transferred to CSR #122 - the three above issues are addressed by a WIP PR that needs to be completed.
• rcgen should refuse emply subject_alt_names #73 - unstarted, could probably be rolled into the WIP PR mentioned above.
• serialize_der() regenerates the certificate #62 - unstarted, but a significant foot-gun that should be addressed soon.
• Tighten up string type representations to prevent illegal values #181 - unstarted
• Basic Constraints certificate extension #68 - unstarted
• Support multiple DnValue per key in DistinguishedName #81 unstarted
• switching to pki-types and rustls-pemfile - unstarted - needs discussion.

In my view there's a good amount of work left to do that will require a comparable version bump. I think this means we have a choice between:

1. Cutting a 0.12.0 release that includes only the changes that are close to being completed, and then later (O(~weeks)) cutting a 0.13.0 that addresses some of the remaining work.
2. Holding 0.12.0 for longer, and addressing more of these changes in one go and then trying to support 0.12.0 with fewer future API changes.

[brocaar]

What would be the "cost" of doing multiple smaller releases compared to one big release? In general, I prefer smaller but more often releases than less often and bigger releases. Thus I would be in favor of 1).

[djc]

Yeah, I think it makes sense to do a smaller release sooner. Personally I would be motivated to get the pki-types + rustls-pemfile transition in soon if we're agreed that that is the right path forward. Maybe we should also get #62 in since it might need a fairly involved API change and is a bit of a footgun?

[est31]

I also prefer multiple smaller releases over few big ones. I don't think we need to wait for #170. #190 would be nice but if we can't get it merged this week we should just make the 0.12.0 release without it (it's a separate crate anyways, we should probably talk about the release schedule of that one, should it be always aligned with rcgen, should it follow a different schedule, etc).

[cpu]

Great, so it sounds like everyone would favour getting a release out sooner than later 👍

#190 would be nice but if we can't get it merged this week we should just make the 0.12.0 release without it

It looks like #190 will land once the OP addresses the last couple small comments. Not including #170 sounds fine to me.

Maybe we should also get #62 in since it might need a fairly involved API change and is a bit of a footgun?

I agree, but also haven't tried to come up with a better design yet. I think it would be helpful to have some proposals in-hand to decide whether it seems likely we can turn around the fix quickly or if it will take longer in review to arrive at a replacement everyone likes.

[est31]

Maybe we should also get #62 in since it might need a fairly involved API change and is a bit of a footgun?

I have added a comment to #62 for my proposed solution. It does need an API change that is a bit involved. We can also nudge people to the new API however via #[deprecated]. I think we will probably do 0.13 pretty soon (less than 6 months after 0.12).

[est31]

Can we make 0.12 on the weekend? I prefer not to wait with this too much. We can do 0.13 at any time when we feel ready.

[cpu]

My vote would be to wait. This weekend feels too soon. We need to prepare and review a changelog update describing the breaking changes, #190 is no longer ready to be merged, and while I've started on a branch for #62 it requires reviews and addressing any feedback.

[est31]

The changelog update is done quickly, I offer to do it. I think for users it's quite useful to be able to use ring 0.17 sooner rather than later, or not even use ring at all if they wish so. Then after the release, we can work on 0.13 without pressure. Pressure is not good :).

[cpu]

Ok, you make a good point :-) SGTM

[est31]

#202

[artsbentley]

can we add #157 to 0.12 now that it's passing?

[cpu]

I think it makes sense to try and land #157. It looks like there are some new suggestions on that branch to make review easier.

If merged it would be included in a new 0.13 release alongside other breaking changes in main.