ddb3f559f2
Версия 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>
63 lines
4.5 KiB
Markdown
63 lines
4.5 KiB
Markdown
# Версия 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:256–262`), а не с версией пакета. Значит
|
||
обновлятор может считать обновление доступным и скачать 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). Это отдельная задача, здесь её решать не нужно.
|