Repository navigation
(PART 2) Renames old livekit-uniffi builds to use ffi instead post livekit-ffi / livekit-uniffi merge - #1439
Conversation
6ad2d1e to
f64b31c
Compare
Changeset ✓This PR includes a changeset covering all affected packages:
|
|
@pblazej Per #1438 (review), can you give me an approval on the PR so I can merge the whole stack at once? |
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
There was a problem hiding this comment.
Devin Review found 1 potential issue.
2 flags not posted on this PR by your GitHub settings — view them in Devin Review. (Configure)
| SPM_NAME = "LiveKitUniFFI" | ||
| DART_PACKAGE_NAME = "livekit_uniffi" | ||
| SPM_NAME = "LiveKitFFI" | ||
| DART_PACKAGE_NAME = "livekit_ffi" |
There was a problem hiding this comment.
🔴 First Dart release cannot publish
When a release first publishes livekit_ffi, the automated pub.dev publish fails. The manual first publish and automated-publishing settings for livekit_uniffi do not carry over to the new package.
Learn more
The package name in the generated pubspec comes from DART_PACKAGE_NAME via the pubspec template. The release job immediately runs dart pub publish --force for that name. pub.dev's initial manual publish and automated publishing configuration belong to an individual package identity; the workflow's bootstrap note describes the old package, not the new one. Without a manual first version and new automated publishing setup, the first tag-push publication cannot succeed.
Example: A tag for version 0.12.83 generates name: livekit_ffi. The release job authenticates through OIDC and tries to publish that package, but pub.dev has only been set up to automate livekit_uniffi; the new package is not published.
Recommended fix: Bootstrap livekit_ffi with a manual first publication, configure its own pub.dev automated publishing for livekit-ffi/v{{version}}, and update the workflow's bootstrap instructions before enabling the new package's automated release.
Was this helpful? React with 👍 or 👎 to provide feedback.
There was a problem hiding this comment.
@hiroshihorie Do you think it's worth creating a new pub.dev package called livekit_ffi here, or should I keep the package name in this one spot livekit_uniffi?
There was a problem hiding this comment.
I think its fine to create a new one 🙂
pblazej
left a comment
pblazej
left a comment
There was a problem hiding this comment.
Would be great if you monitor the CI for a while 🧨
f64b31c to
24b8f51
Compare
…fi` with `room-apis` and`core-modules` modes (#1438) ## Background Ever since we [introduced livekit-uniffi](#750) at the start of 2026, it has been getting increasingly confusing what the difference between `livekit-ffi` (existing C ABI ffi solution used by python, node, unity, and c++ sdks that exposes a full rust owned webrtc stack) and `livekit-uniffi` (new uniffi powered ffi solution used by swift, android, and flutter that exposes utility modules) actually are to those that haven't been intimately involved with the rust adoption initiative. This has become even more confusing now that we have recently [added uniffi to the livekit-ffi crate](#1308)... 😬 The original intention was that `livekit-uniffi` would be a somewhat transitional "playground" we could use to experiment with uniffi and make sure we were ready to commit to it before moving everything wholesale over to it. We're now at the point where we're ready to commit to it, so this change aims to consolidate all FFI usage (both C ABI FFI and uniffi flavors) into one monolithic `livekit-ffi` crate again. ## Overview Moves all code from `livekit-uniffi` into `livekit-ffi` and **outright removes** the `livekit-uniffi` crate. This implements "phase 3" of the C ABI -> uniffi migration plan document discussed last month. `livekit-ffi` now has two top level "modes" controlled by features: - The `room-apis` mode is exactly what `livekit-ffi` used to be - the C ABI ffi stack using the `livekit` crate that manages a full webrtc stack. This build is still built in ci exactly as it was before, and consumed by python/node/unity/c++. - The `core-modules` mode ie exactly what `livekit-uniffi` used to be - the newer uniffi exposed set of utilities which are consumed by the swift, android, and flutter sdks. ## Common functionality As we migrate the `room-apis` mode to fully use uniffi, there will inevitably be bits and pieces we want to expose to both "modes". This pull request surfaced one initial candidate - the `build_version` function. This was exposed identically in both old uniffi implementations so now this is defined once and not gated by either "mode". ## Backwards compatibility This pull request _should_ be fully backwards compatible. That means in practice that "core modules" builds will still include identifiers within that mention `uniffi` - ie, `LiveKitUniFFI` in swift, etc. I've broken out a second step to this process in #1439 which actually cuts over the names to the new `ffi` naming, but as this is a breaking change we'll need to ensure that all downstream sdks do this update in lock step. We can also choose to not merge this second step if it is going to be too disruptive and the resulting naming debt is deemed acceptable. ## TODO - [x] Fix the dual versions of prost (`prost` vs `prost_012`) which seem to have made their way in because `livekit-ffi` and `livekit-uniffi` had different versions in use. Standardize on whatever the repo uses generally. - This has been done and broken out into a separate PR (#1447) - [x] Rebase on top of `main` once #1447 merged.
…FI identity Every commit before this one keeps the names that the Swift, Android and Flutter SDKs use today. This commit changes them, and it is the only commit that does. Hold it back or move it to its own pull request if the rename is not wanted now. The Swift package and product become LiveKitFFI and RustLiveKitFFI. The Maven artifact becomes io.livekit:livekit-ffi-android with the Kotlin package io.livekit.ffi. The package on pub.dev becomes livekit_ffi. Both surfaces now use the crate name as their UniFFI namespace. Rename the podspec template with the package. The cargo-make task builds its file name from the package name, so the old name would stop the Swift release with a missing template. The repository that holds the Swift framework keeps its current name. Only the package and the product inside it change. BREAKING CHANGE: imports, dependency coordinates and generated module names all change together for the Swift, Android and Flutter SDKs. Before the first release, publish livekit_ffi to pub.dev by hand and set its tag pattern, because pub.dev automates only a package that exists. Also remove the old source directory from the framework repository.
`export FLAGS=$(...)` is a builtin whose own exit status is 0, so `set -e` never saw `ffi_features.py` fail. FLAGS would be empty and the build fell through to `cargo build -p livekit-ffi` with no feature flags -- the default feature set, room-apis -- quietly producing the wrong surface and publishing it to pub.dev as the Dart cdylib. Splitting the assignment from the export restores the check: a plain assignment carries the command substitution's status, so the step now aborts before `docker run`. Verified both paths: a failing resolver exits 2 without reaching the docker step, and the success path still exports `--no-default-features --features core-modules` into the container. This was the only affected call site. The other invocations here and in livekit-ffi/Makefile.toml already use a plain assignment, and cargo-make's `@shell` runner does propagate a failed command substitution (checked against cargo-make 0.37.24). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
24b8f51 to
cc45089
Compare
3 participants
Adds onto the base livekit-ffi / livekit-uniffi merge pull request and renames a bunch of lagging symbols from "uniffi" to be "ffi". This is the breaking part of this change. We decided it makes most sense to merge both parts right after another.