Filed by release-pilot after shipping audioif v0.3.0 (tag `v0.3.0` = 7f52f9273e77b0593712010318beed51f9afa83b), so the lag is written down rather than noticed later.
State. `AUDIOIF_PATCHES_COMMIT` = `667cb0f30debc3d11baff7872f652e7b95c4a7c9`. `patches/adafruit_mp3/` here is byte-identical to that pinned commit, so `scripts/sync_from_overlay.sh --check` reports no drift and will keep reporting none — the check compares the mirror against the pin, so by design it says nothing about newer audioif commits. That is the reason this needs a note.
What audioif has changed since the pin (`git diff 667cb0f3 v0.3.0 -- patches/adafruit_mp3`): 2 files, +30/-3, and it is all provenance —
- `0001-windows-msvc-inline-assembly.patch` gained a 27-line `From:/Subject:/Purpose:/Provenance:/Upstream-version:/Order:/Test:` header, and one in-patch comment now points at `docs/upstream-diff.md` in the audioif repo instead of the retired `cmods/micropython-audio/docs/upstream-diff.md`.
- `README.md`: one line, same re-pointing.
No compiled behaviour changes — the only edit inside the patch body is a C comment. So this is a tidiness bump, not a firmware-affecting one, and it is safe to fold into the pin move rather than doing it now.
Why I did not do it. Bumping means `scripts/sync_from_overlay.sh` without `--check`, and that single run also resyncs the `micropython-pydevices` mirrors and rewrites `MICROPYTHON_PYDEVICES_COMMIT` — which is exactly the pin the CircuitPython 10.3.0 / MicroPython 1.29.0 / ESP-IDF 5.5.4 move is mid-flight on, in a tree that currently has local modifications. Whoever finishes the pin move should run it once and commit `AUDIOIF_PATCHES_COMMIT` with the rest.
`cmods/audioif` itself is a symlink to the sibling checkout, which is now on `main` at 491b975 (v0.3.0 plus one CHANGELOG commit), so builds already see the released sources; only the mirrored MP3 patch and its pin file lag.
Filed by release-pilot after shipping audioif v0.3.0 (tag `v0.3.0` = 7f52f9273e77b0593712010318beed51f9afa83b), so the lag is written down rather than noticed later.
State. `AUDIOIF_PATCHES_COMMIT` = `667cb0f30debc3d11baff7872f652e7b95c4a7c9`. `patches/adafruit_mp3/` here is byte-identical to that pinned commit, so `scripts/sync_from_overlay.sh --check` reports no drift and will keep reporting none — the check compares the mirror against the pin, so by design it says nothing about newer audioif commits. That is the reason this needs a note.
What audioif has changed since the pin (`git diff 667cb0f3 v0.3.0 -- patches/adafruit_mp3`): 2 files, +30/-3, and it is all provenance —
No compiled behaviour changes — the only edit inside the patch body is a C comment. So this is a tidiness bump, not a firmware-affecting one, and it is safe to fold into the pin move rather than doing it now.
Why I did not do it. Bumping means `scripts/sync_from_overlay.sh` without `--check`, and that single run also resyncs the `micropython-pydevices` mirrors and rewrites `MICROPYTHON_PYDEVICES_COMMIT` — which is exactly the pin the CircuitPython 10.3.0 / MicroPython 1.29.0 / ESP-IDF 5.5.4 move is mid-flight on, in a tree that currently has local modifications. Whoever finishes the pin move should run it once and commit `AUDIOIF_PATCHES_COMMIT` with the rest.
`cmods/audioif` itself is a symlink to the sibling checkout, which is now on `main` at 491b975 (v0.3.0 plus one CHANGELOG commit), so builds already see the released sources; only the mirrored MP3 patch and its pin file lag.