livekit-ffi migration, phase 0 - #1308
Conversation
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| #[uniffi::export] | ||
| pub fn build_version() -> String { | ||
| env!("CARGO_PKG_VERSION").to_string() | ||
| } |
There was a problem hiding this comment.
🟡 Release notes entry missing for the version-reporting change
The change adds new functionality to the FFI package without adding the required release-notes file (no new entry alongside the existing ones in /.changeset), so the affected package will not be version-bumped or documented on release.
Impact: The new capability ships without a version bump or changelog entry, so consumers can't tell which release contains it.
Repository rule: every PR must include a changeset listing crates to bump
AGENTS.md ("Documenting changes") states: "Every PR needs a changeset" and "Changeset must list any crates which need to be bumped stemming from the change". This PR adds livekit-ffi/src/build_info.rs (a new public build_version UniFFI export) plus a new tools/bindgens crate, but /.changeset only contains the three pre-existing files (fix-publisher-renegotiation-deadlock.md, fix_nvenc_dynamic_bitrate_updates.md, fix_uniffi_android_package_build.md). A new changeset marking livekit-ffi should be added.
Prompt for agents
AGENTS.md requires every PR to include a knope changeset under /.changeset listing the crates that need bumping. This PR adds a new public UniFFI-exported function (build_version) to livekit-ffi and a new tools/bindgens crate, but no changeset file was added. Create a changeset (e.g. via `knope document-change`) describing the uniffi migration phase 0 change and marking `livekit-ffi` for the appropriate bump level.
Was this helpful? React with 👍 or 👎 to provide feedback.
jhugman
added
the
internal
|
Should this have a changeset for |
2 participants
This PR introduces uniffi to the
livekit-fficrate, and the smallest possible additional functionality.This corresponds to Phase 0 of the plan documented here.
Before you submit your PR
Make sure the following is true before submitting your PR:
PR description
Describe the changes in this PR. Explain what the PR is meant to solve and how to reproduce the issue in the first place.
Breaking changes
If this PR introduces breaking changes, list them here and document the rationale for introducing such a change.
MSRV
If the PR modifies the crate's MSRV (Minimum Supported Rust Version), document it here.
Testing
Ideally, unit test the code you add, but ensure you're not repeating existing test cases. Use as many already written scaffolding, utilities as possible; write your own, when needed. If external services, APIs, tokens are required (e.g., running an LK server instance), provide the necessary information. Make sure your tests perform useful, context-aware assertions and do not simply emulate "happy paths".
Async
We want the project to be runtime-agnostic, so please reuse what's already in livekit-runtime and feel free to add anything missing. It's ok to use Tokio directly, when writing unit tests, if necessary. When testing, do not use artificial delays for the state to "catch up"; instead, respect the event flow and subscribe properly using channels or other mechanisms.