Обновление: консольные команды

[AltGrF13]

Когда будет сделана #234 (только после этого, просто записываю задачу заранее); то станем уверены, что установка "на лету" ничего не ломает. Можно дорабатывать привычные команды. Чтобы использующие бету могли удобно обновляться параллельно использующим 1.1.8 (для тех и тех последняя версия будет своя).

1. Можно заводить на GitHub новые релизы так, чтобы не вызвать обновление использующих 1.1.8? (Не работал с этим). Вроде бы, согласно документации:

Optionally, to notify users that the release is not ready for production and may be unstable, select This is a pre-release.

Optionally, select Set as latest release. If you do not select this option, the latest release label will automatically be assigned based on semantic versioning.

Т.е. можно добавить новую версию как unstable, а потом обратно пометить 1.1.8 как последнюю-стабильную; и это не вызовет обновление у использующих старую версию?

1.1. Если это так, то можно завести для новых релизов "tag_name": "v2" (да, это не совсем прямое использование тегов ГитХаба, но оно подходит). И в бете изменить, чтобы она проверяла не https://api.github.com/repos/qzeleza/kvas/releases/latest, а свой тег. Вот, например, как выглядит сейчас проверка последней версии внутри имеющегося старого тега https://api.github.com/repos/qzeleza/kvas/releases/tags/v1.1.6 И тогда бета начнёт обновляться внутри своего "канала" обновления.

1.2. Если это не так, то распишу позже

2. Вроде бы уже подымался вопрос. Большинство flow настаивают на:

Семантическое версионирование всем облегчит жизнь, потому что люди, лишь посмотрев на номер версии, будут знать, когда именно были внесены критические изменения, или содержит ли версия новые фичи или исправления багов.
Учитывая шаблон MAJOR.MINOR.PATCH, увеличивайте:

• Старшую (MAJOR) версию, если вносите несовместимые с предыдущими версиями изменения в API.
• Младшую (MINOR) версию, если добавляете обратно совместимую функциональность.
• Патч-версию (PATCH), если вносите обратно совместимые исправления ошибок.

В качестве расширений шаблона MAJOR.MINOR.PATCH можно использовать дополнительные метки для пререлизов и сборок. Помимо изменения версии package.json, рекомендую для каждой версии генерировать git-тег.

Ну т.е. в их терминах текущая версия — это полноценная 2.0. Ибо изменился формат хранения списков (звёздочки как несовместимое изменение); базовая вещь при установке и эксплуатации (выкидывание встроенного DNS с 53 порта с перезагрузками и потерей интернета); подход к проверке попадания в обход (ipset на лету вместо обхода и альтернативное видение часто используемого test). Это наиболее частые практики из старой версии, не подходящие новой; на самом деле их гораздо больше.

Если мы восстанавливаем удобное обновление через команду (в пункте 1), то переименовыванию тут самое место. Изменение старшей версии явно напряжёт пользователей; даст им подсказку, что обновление "большое". Хоть оно будет и в отдельном канале обновления.

3. kvas upgrade и kvas reset — команды опасные. Нужно добавить вопрос пользователю. Что-то вроде: Текущая версия блабла, есть новая версия блабла. Вы уверены, что хотите обновиться (сбросить пакет)?
4. И типичный кейс — при проверке версии проверять уведомление. Возможно, команды вообще стоит склеить в одну.