docs: update CHANGELOG for 0.13.0

[cpu]

I've included substantially more detail in this CHANGELOG update compared to previous. To try and keep the top level content manageable, while also balancing making updates as friction-less as possible, I've split off some separate migration help to its own document.

I've done my best to flag all of the important changes but would appreciate more eyes to make sure I haven't missed or misrepresented anything. Like previous updates I've called out contributions by external folks and not those by core maintainers.

[djc]

I would reorder these with breaking changes before added and with both lists ordered from most to least impact.

[cpu]

I would reorder these with breaking changes before added and with both lists ordered from most to least impact.

Good idea. I've done a reordering pass.

[djc]

Order looks great!

I think it's great to spend more words on the larger changes in the signing API, but (especially when also adding CRLs) I wonder if it could be done more concisely by explaining the general principles and abstracting as much as possible over certificate/CSR/CRL. I've tried hard to make the APIs as similar as possible for each of them.

I like to retain the () suffix on methods/functions because it makes it more obvious to distinguish these from types/variables.

[cpu]

I wonder if it could be done more concisely by explaining the general principles and abstracting as much as possible over certificate/CSR/CRL.

Yeah, I think that's good feedback 👍 I will try and rework along these lines tomorrow.

[cpu]

I think it's great to spend more words on the larger changes in the signing API, but (especially when also adding CRLs) I wonder if it could be done more concisely by explaining the general principles and abstracting as much as possible over certificate/CSR/CRL. I've tried hard to make the APIs as similar as possible for each of them.

I went back and replaced the CHANGELOG.md coverage with a section aiming to explain the general principles without explicitly listing the mechanical changes. I think that's a good level of detail for a CHANGELOG and fits better with the existing practices.

But... I think the Rustls releases & feedback have shown me that there's also an audience for material that is much more explicit about what changed and what should be used instead. I've split off some of that content into a separate rcgen/docs/0.12-to-0.13.md document. It's probably overkill to do that for every release but I felt like it was worthwhile for this one. I'd like to try and make sure the process is as painless as possible for consumers.

I like to retain the () suffix on methods/functions because it makes it more obvious to distinguish these from types/variables.

Makes sense. I've done a pass adding them in both for the CHANGELOG and migration guide document.

[cpu]

@est31 I think this is ready for review now and the last thing blocking a 0.13 release. If you're comfortable approving the branch can I go ahead and publish the release afterwards? It would be great if we could do this before your availability is reduced :-)

[est31]

LGTM, let's release 0.13

[djc]

• Created v0.13.0 tag
• Published rcgen v0.13.0 at registry crates-io

[cpu]

Thanks for finishing this up djc 🚀