biscuit-auth 6.0.0 release plan

[divarvel]

The main element of the release is support for biscuit 3.3. Since support for biscuit 3.3 is a breaking change for the library (interpretation of the biscuit datalog text representation has changed), a few other breaking changes have been integrated as well.

Here are the most important changes compared to biscuit-auth 5.x (all changes are tracked in CHANGELOG.md files for each crate).

• biscuit-datalog 3.3 support, including support for P256 signatures
• Improvements on the authorizer API (most notably extracting AuthorizerBuilder)
• More explicit serialization for private and public keys (embed the algorithm, differentiate public and private keys)
• Support for PEM/DER key serialization

There is one outstanding PR (#266) for testing a more efficient way to compute signatures, but it’s still in draft and not a blocker for a 6.0.0 release.

The three 6.0.0-beta releases have allowed making sure the API changes play well with the rest of the ecosystem (tooling such as biscuit-cli and biscuit-web-components, bindings such as biscuit-wasm and biscuit-python). They also have been tested in private projects.

There also has been work on biscuit-c, which has been traditionally released alongside biscuit-rust. It has been moved to a separate crate in the workspace and its API has been improved as well. We can consider a sync release if that makes sense. @ptondereau, how do you feel about this?

biscuit-c notwithstanding, I think biscuit-auth is ready for a stable release.

[ptondereau]

Thanks for the heads-up!
The PHP extension is still in a WIP state, so I'll take the last version as a start point (and I actually use the v6 branch anyway).
The main concern for me with a C API is how to distribute it: it involves maybe packaging/embedding etc...
I can embed the C lib itself with the PHP extension, but it means that we need to fetch it from somewhere (GH release, packager manager, etc...).

[divarvel]

all right. I think it would make sense to de-correlate the release cycles for biscuit-rust and biscuit-c then, and issue dedicated releases for biscuit-c (once the general api of biscuit-c is stabilized, the release cycles will be a bit more in sync)