Comments 4
Знаю, статью написал ИИ, но все же интересно узнать мнение:
Если библиотека работала под Windows 10 и выше, а изменение убирает поддержку "устаревшей" Windows 10, как по-вашему должна измениться версия библиотеки?
Как вы думаете, стоит ли в SemVer поменять название частей с MAJOR.MINOR.PATCH на BREAKING.FEATURE.FIX?
Есть ли смысл использовать SemVer в версионировании приложений? Если да, по какому принципу инкрементировать каждую часть версии?
Нет, статью писал я лично, и кучу других в моем тг
https://t.me/IlyaIvanchikov
Только авторский текст.
Далее ответы на ваши вопросы
1) я считаю что это мажор и никак иначе, мажорный апдейт не означает, что должно заафектить всех, если даже для одного клиента это будет breaking changes, мы не имеем права не сказать ему об этом.
2) Думаю не стоит менять и нет в этом необходимости, есть устоявшаяся терминология, качели ни к чему.
3) Конечно лучше использовать, версионирование делает вашу апку прозрачной, приятной и понятной для тех, кто захочет ей пользоваться.
Сори за некропостинг
Пример 1-о пункта:
некоторые крупные библиотеки/инструменты в JS экосистеме делают мажорное изменение только потому, что прекращают поддержку старой (не актуальной) версии ноды. А все остальные изменения в релизе - минорные.
Так что прекращение поддержки 10-й винды - это мажорное изменение.
3-й пункт:
Я считаю, что надо пользоваться SemVer и в "важности" изменений надо отталкиваться от UI/UX. Или от добавления нового доступного "контента". То-есть то, что пользователь в конечном итоге может РЕАЛЬНО увидеть. Масштабные переработки внутреннего устройства приложения с сохранением старого функционала и старого интерфейса - это НЕ мажорные изменения.
Мажорное изменение:
1. Масштабная переработка UI/UX
2. Изменение требований к платформе пользователя (обновление винды, требование видеокарты с определённой технологией)
3. Удаление/сплющивание некоторого функционала (по большей части с точки зрения UI/UX)
Про последний (3-й) пункт - тут не однозначно. Если не планировать релизы, то каждый 2-й релиз будет мажорным. Тогда потеряется важность "мажорного" релиза. Надо ИЛИ объединять такие моменты в 1 релиз ИЛИ разделять "удаление" функционала и "объединение". В случае объединения делать минорный релиза, в случае удаления - мажорный
Минорное изменение:
Добавление нового функционала без переработки всего UI/UX
"без переработки" - добавили кнопку в модалку ИЛИ в менюшку ИЛИ добавили новую менюшку/опцию
Патч изменение:
Правки багов
Наработки на будущее без добавления нового функционала
Оптимизация приложения
Я согласен с вами, но только частично.
У semver есть правило, мажор это все то, что может сломать api, ui и так далее, расширение функционала это не мажор, это как O в SOLID, не сломал старое, тогда и не может быть это мажором.
Если у вас есть желание, переходите в телеграм канал, там и чат есть, где можем эту тему разогнать. t.me/IlyaIvanchikov
Что требуется знать о семантическом версионировании (SemVer)