server-monitor-manager/agents/codex/inbox/2026-08-20-msix-version-stuck.md
Ochenstarik ddb3f559f2 chore(agents): задания по Windows-клиенту и второму потребителю cosign
Версия MSIX не менялась с 2026-07-31: Package.appxmanifest объявляет
1.0.0.6 во всех четырнадцати релизах после alpha.6, тогда как Windows
различает пакеты по версии манифеста. UpdateService при этом сравнивает
версию манифеста с именем тега, а не с версией пакета.

В задание по cosign добавлен второй потребитель: Windows-обновлятор
закрепляет cosign v2.4.0, тогда как Linux-установщик — v3.1.3. Подпись
одного релиза проверяется двумя разными версиями, а Release Verification
покрывает только Linux-путь.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 16:47:48 +07:00

4.5 KiB
Raw Blame History

Версия MSIX не менялась 14 релизов подряд

  • Кому: codex
  • Дата: 2026-08-20
  • От кого: главный агент (claude)
  • Ветка: codex/msix-version
  • Файл отчёта: ../done/2026-08-20-msix-version-stuck.md

Что нужно сделать

src/ServerMonitorManager.Desktop/Package.appxmanifest:13 содержит Version="1.0.0.6". Последний раз её меняли 2026-07-31 коммитом c320b7d «chore(release): bump MSIX version to 1.0.0.6 (#9)» — то есть под v0.1.0-alpha.6. С тех пор выпущено четырнадцать версий, вплоть до v0.1.0-alpha.20, и в каждой из них MSIX объявляет себя как 1.0.0.6.

Windows различает пакеты по версии в манифесте, а не по имени файла и не по тегу GitHub. Установка нового MSIX поверх уже установленного с той же версией не считается обновлением.

Нужно:

  1. Определить фактическое поведение: устанавливается ли MSIX из alpha.20 поверх установленного MSIX из alpha.14, и что именно происходит. Пока это не определено — я проверял чтением дерева, не установкой.
  2. Если обновление действительно не проходит — связать версию пакета с версией релиза, чтобы она поднималась при каждом выпуске автоматически, а не руками.
  3. Учесть, что UpdateService сравнивает версию манифеста с именем тега релиза (UpdateService.cs:256262), а не с версией пакета. Значит обновлятор может считать обновление доступным и скачать MSIX, который Windows затем откажется ставить. Проверить эту связку целиком.

Границы

Package.appxmanifest, скрипты сборки Windows-установщика (build/windows/**) и, если потребуется, windows-release.yml. Не менять логику UpdateService без отдельного основания: сначала измерение, потом правка. Не трогать src/** вне Desktop, консоль и Linux-часть.

Как проверить результат

  • вывод Get-AppxPackage до и после установки: версия должна отличаться;
  • показать установку MSIX новой версии поверх предыдущей на машине, где предыдущая уже стоит, и её фактический результат;
  • если решение автоматизирует поднятие версии — показать два прогона сборки с разными тегами и разные версии в получившихся манифестах.

«Версия теперь поднимается» без установки поверх предыдущей результатом проверки не является: проблема ровно в установке.

Контекст и ограничения

Дефект найден чтением дерева и истории git, установка не выполнялась: на машине разбора нет ни .NET SDK, ни установленного пакета. Если при проверке окажется, что Windows нормально ставит MSIX той же версии поверх себя, — так и напиши с выводом команд; это допустимый результат.

MSIX подписан тестовым сертификатом (Publisher="CN=AppPublisher", ассет ServerMonitorManager-test-signing.cer), поэтому для установки нужен импорт этого сертификата в доверенные корневые. Постоянная доверенная Windows code-signing identity в docs/roadmap.md числится невыполненной (этап 6). Это отдельная задача, здесь её решать не нужно.