biscuit-auth
biscuit-auth 6.0.0 release plan
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 (https://github.com/eclipse-biscuit/biscuit-rust/pull/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.
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...).
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)