17 марта: конвергенция CI и завершение релизов

17 марта 2026 — Конвергенция CI и завершение runtime релизного образа (v2.32.12)

Релиз 2.32.12 — узкое, но важное продолжение 2.32.11. Предыдущий релиз намеренно ужесточил CI и релизную валидацию, но первые живые прогоны обнажили два оставшихся пробела: один в согласованности линтинга между локальными хуками и GitHub Actions, и второй — в фактическом составе зависимостей релизных образов, собранных с привязкой к конкретной версии sendspin. Этот релиз закрывает оба пробела, так что pipeline валидации стал не только строже, но и внутренне согласованным.

Два момента определяют релиз:

Линтинг теперь сходится на том, что кодовая база должна принимать — репозиторий больше не полагается на source-level noqa, который означает разное для разных entry point’ов Ruff. Вместо этого локальный pre-commit хук явно ослабляет UP038, что сохраняет runtime-безопасный синтаксис isinstance(..., (list, tuple)) для локальных окружений с Python 3.9, при этом оставляя собственный ruff check в CI чистым и предсказуемым.
Релизные образы теперь содержат тот runtime, валидацию которого они заявляют — не-armv7 Docker-путь релиза больше не устанавливает привязанный sendspin с --no-deps. Это значит, что smoke-tested образы теперь действительно включают aiosendspin, av и остальной граф пакетов, необходимый sendspin в runtime, вместо того чтобы проходить сборку и падать только при реальном запуске собранного контейнера.

Это именно тот тип релиза, который должен быть маленьким: он не добавляет новую функцию, а убирает оставшееся расхождение между локальными ожиданиями, CI-валидацией и содержимым публикуемого runtime-образа.

17 марта 2026 — Продолжение CI-упаковки и list-first dashboard по умолчанию (v2.32.11)

Релиз 2.32.11 — компактное продолжение 2.32.10, но он закрывает очень практический разрыв между «код готов» и «релизная механика действительно заслуживает доверия». После того как предыдущий релиз был опубликован, GitHub Actions обнажили несколько допущений об окружении, которые были верны локально, но не на hosted-раннерах. Этот релиз ужесточает эти допущения, чтобы pipeline вёл себя одинаково в CI и в реальных средах деплоя.

Три корректировки определяют релиз:

Dashboard теперь открывается в layout’е, который лучше всего работает как операционное представление по умолчанию — новые сессии стартуют в list view, который плотнее, удобнее для сканирования и лучше соответствует мониторинговой роли текущего dashboard. При этом выбор пользователя не перезаписывается: любой ранее сохранённый вариант в localStorage по-прежнему приоритетнее.
Подготовка релиза теперь явно учитывает нативные требования сборки D-Bus — путь определения версии в Docker publish workflow теперь устанавливает пакеты разработки D-Bus, необходимые для dbus-python, до считывания версии упакованного sendspin. Это убирает класс CI-only сбоев, при которых релизный pipeline ломался ещё до начала фактической сборки образа.
Smoke-тесты совместимости теперь обеспечены так же, как и код, который они проверяют — lint/test workflow устанавливает runtime-библиотеку PortAudio перед запуском проверки совместимости sendspin, а условная ветка зависимостей в Dockerfile теперь использует hadolint-совместимую структуру elif. Вместе эти фиксы превращают новые релизные гейты из «правильных в принципе» в «надёжных в автоматизации».

Это не feature-heavy релиз. Это релиз про то, чтобы сделать дефолты и pipeline доставки честнее: UI стартует в наиболее практичном обзорном режиме, а CI-система теперь содержит нативные компоненты, которые ей реально нужны для валидации того, что мы отправляем.

17 марта 2026 — Релизная дисциплина, операционная видимость и UX-доработки воспроизведения (v2.32.10)

Релиз 2.32.10 связывает воедино несколько потоков, каждый из которых уменьшает неоднозначность в повседневной эксплуатации. Часть изменений — ужесточение релизного процесса под капотом, часть — улучшение диагностики, а часть — небольшие, но очень заметные фиксы dashboard — но все они движутся в одном направлении: сделать поведение bridge более предсказуемым как для операторов, так и для конечных пользователей.

Четыре темы определяют релиз:

Создание релиза теперь явная операция, а не случайный побочный эффект тегирования — GitHub-релизы теперь обрабатываются выделенным ручным workflow. Он по умолчанию берёт последний тег, по-прежнему позволяет выбрать конкретный тег, генерирует кумулятивные release notes от предыдущего опубликованного релиза и обновляет ha-addon/config.yaml только при создании самого релиза. Push тегов больше не перезаписывает метаданные add-on молча.
Совместимость зависимостей видна и проверяется раньше — bridge теперь записывает разрешённые версии runtime-зависимостей в startup-логах, диагностике, bugreport’ах и /api/version, а CI и Docker-пути релиза включают реальную smoke-проверку совместимости с установленным runtime sendspin. Это делает drift upstream проще обнаружить до публикации и намного проще диагностировать после деплоя.
Серьёзность инцидентов теперь ближе к операционной реальности — crash-like stderr подпроцессов больше не сплющивается в обычный warning. Runtime-логгер, bugreport summary, вывод диагностики и affordance Report an Issue теперь разделяют одинаковое понимание того, какие строки логов действительно представляют actionable-сбои.
UI воспроизведения получил очередную волну polish для укрепления доверия — фильтр-панель dashboard теперь остаётся видимой даже для одного плеера, кнопки shuffle / repeat в card-view наконец ясно показывают своё активное состояние, а repeat one теперь использует интегрированную иконку вместо наложенного badge. Это мелкие детали, но они важны, потому что элементы управления транспортом должны мгновенно и однозначно передавать состояние.

Это не релиз «одной большой функции». Это релиз про устранение тихих источников путаницы: путаница во владении релизами, путаница в составе упакованных зависимостей, путаница в серьёзности логов и путаница в обратной связи UI транспорта. Такого рода расчистка имеет свойство хорошо стариться.

17 марта 2026 — Хотфикс совместимости запуска HA add-on для drift `DaemonArgs` (v2.32.9)

Релиз 2.32.9 — узкий, но важный хотфикс к 2.32.8. Сам bridge не регрессировал в логике маршрутизации Music Assistant, но Home Assistant add-on мог упасть ещё до запуска каких-либо подпроцессов плееров. Коренная причина — проблема на границе упаковки: наш daemon launcher по-прежнему предполагал, что sendspin.daemon.daemon.DaemonArgs принимает use_hardware_volume, тогда как установленная версия sendspin в некоторых средах HA add-on больше не предоставляла этот keyword.

В этом релизе важны три вещи:

Совместимость запуска вместо жёстких допущений о kwarg’ах — daemon-подпроцесс теперь формирует payload DaemonArgs защитно, фильтруя startup kwargs по сигнатуре, которую реально предоставляет установленный пакет sendspin. Если более старая или новая сборка sendspin пропускает поле вроде use_hardware_volume, bridge пропускает этот kwarg вместо того, чтобы падать при запуске.
Восстановление HA add-on из немедленного сбоя при загрузке — это именно фикс пути загрузки. Он восстанавливает способность add-on стартовать после обновления 2.32.8 в средах, где API-поверхность упакованного sendspin разошлась с ожиданиями bridge.
Покрытие регрессии для фильтрации совместимости — релиз добавляет тесты вокруг поведения фильтрации kwarg’ов, чтобы будущий drift API Sendspin с большей вероятностью проявился как целевой тестовый сбой, а не как production-crash при запуске.

Это тот тип релиза, который существует для возвращения скучной надёжности: никаких UI-изменений, никакой новой семантики транспорта, просто более жёсткая граница совместимости между bridge и daemon API упакованного пакета, от которого он зависит.

17 марта 2026 — Восстановление MA-транспорта solo-плееров и спокойный UX apply-state (v2.32.8)

Релиз 2.32.8 — хотфикс к недавней работе над транспортом Music Assistant, но он исправляет вполне реальную эксплуатационную проблему, а не полирует мелочи. Bridge уже был достаточно быстр на уровне MA monitor — queue-команды подтверждались за несколько миллисекунд — и всё же элементы управления транспортом на живом Proxmox-деплое могли выглядеть сломанными. Коренная проблема — drift идентификаторов: dashboard, кэш bridge и Music Assistant не всегда говорили об одном и том же объекте queue.

Три потока определяют релиз:

Целевое указание queue solo-плеера вместо повторного использования устаревших идентификаторов — bridge теперь различает локальный ключ состояния, используемый для обновления кэша dashboard, и фактический MA queue/player ID, который должен получить команду. Это важно для bridge’ей с solo universal-player, где UI-facing bridge player ID и MA queue ID — не одно и то же.
Устойчивость к stale-tab’ам на живых деплоях — если уже открытая страница dashboard продолжает отправлять устаревшие MA target metadata после rollout хотфикса, backend теперь может восстановиться, вычислив правильный активный solo player queue вместо слепого доверия устаревшей подсказке syncgroup. На практике это означает, что элементы управления транспортом восстанавливаются быстрее в реальном мире, а не только после жёсткого обновления браузера.
Более спокойное поведение apply-state — кнопки queue по-прежнему блокируются, пока команда в ожидании, но временное состояние «apply» больше не добавляет дополнительного визуального подсвечивания. Элементы управления просто становятся неактивными, пока команда не завершится, что делает и card-, и list-поверхности воспроизведения спокойнее и менее шумными при обычном использовании.

Это тот тип релиза, который выглядит маленьким в diff, но большим по эффекту: путь MA monitor уже был быстрым, и всё же операторский опыт по-прежнему ощущался сломанным, потому что команды приземлялись не на ту цель или потому что устаревшие runtime metadata пережили хотфикс. 2.32.8 закрывает этот разрыв, делая маршрутизацию queue более явной, более авторитетной со стороны backend и более терпимой к реальным условиям live-деплоя.