Огромное спасибо за такой развернутый ответ! Респект.> Если есть желание действительно разобраться в теме, то ОЧЕНЬ советую почитать их
> багтрекер. Все открытые задачи. Там не так много, за день можно управиться.
ОК, спасибо за наводку.
> Из того, что могу сходу озвучить:
> 1. Нумерация СемВер основана на понятии совместимости, тогда как нумерация софта традиционно
> отталкивается от понятий функционала и/или объёма выполненных работ. Это ортогональные
> понятия.
....
> Плюс с точки зрения софта, если для исправления мелкой ошибки пришлось значительно
> поменять какой-то интерфейс или workflow, то меняется патч-версия. Тогда как в
> случае СемВер, по логике, нужно было бы менять старшую цифру из-за
> несовместимых изменений.
Ну, это можно по ситуации решать, я признаю, что буквально следовать SV очень трудно.
С другой стороны, если приходится значительно менять интерфейс - сложно назвать это "мелкой ошибкой". я бы чинил не ломая, что можно (patch-level), остальное добавил в known issues,
и новый мажорный релиз выпустил с учетом предыдущих косяков.
> 2. СемВер плохо отражает процесс разработки ПО.
> Например, сортировка пререлизных версий идёт по алфавиту. Нам просто повезло, что согласно
> алфавиту alpha < beta < pre < rc. Но добавьте сюда
> ещё какую-нибудь стадию, специфичную для вашего проекта, и очень вероятно, что
> она не впишется в такой порядок.
Честно говоря, не вижу в этом проблемы. Заказчик получает доступ к папке с релизами, а там вполне можно добиться вменяемой сортировки версий. Сами по себе "alpha < beta < pre < rc", такой себе канон, сильно зависит от внутренней модели разработки, "pre" - уже не помню, когда видел последний раз.
>[оверквотинг удален]
> 1.2.3, а модификация патчит эту версию и делает 1.2.3.0. После нахождения
> ошибок в модификации, выпускается 1.2.3.1. После релиза 1.2.4 основного проекта выпускается
> модификация версии 1.2.4.0. Это, конечно, можно переложить на СемВер, но для
> автора "модификации" (да и для пользователей) такой способ выглядит более наглядным.
> Использовать версии типа 1.2.3-modified.1 нельзя, так как это считается пререлизной версией,
> то есть 1.2.3-modified.1 < 1.2.3. Использовать 1.2.3+modified.1 тоже нельзя, так как
> инструмент сравнения версий может игнорировать метаданные, так что может получиться 1.2.3+modified.1
> = 1.2.3+modified.2.
> И лично я вообще не понимаю, зачем им дефис. Почему бы не
> использовать точку: 2.0.0.dev.1.0, всё же понятно.
Имхо, все эти цифры, буквы, плюсы, минусы, точки и т.п. знаки препинания уже болше определяются политикой и совокупностью гайдлайнов дистрибутивов, для которых приложение собирается.
например версия может быть appname-1.2.RC1-ubuntu+master.build3455.2fbf9281
в ней есть major(1),minor(2),patchlevel(RC1-ubuntu+master.build3455.2fbf9281),
при этом patchlevel точно описывает: состояние, под какую ось, из какой ветки взят код, номер билда/хэш коммита/дату билда и т.п.
> 3. В багтрекере вообще периодически встречаются комментарии, что СемВер предназначен для
> разного рода АПИ, и ни для чего другого (правда, я не
> обращал внимания, комментарии ли это мейнтейнеров СемВера или нет). Если версия
> вашего софта можно рассматривать как АПИ, то СемВер применим. Но если
> вы, к примеру, провели масштабный рефакторинг, то ни для пользователя, ни
> с точки зрения совместимости ничего не поменялось. Однако вы в этом
> случае можете счесть приемлемым увеличить мажорную версию.
имхо, всё что угодно можно рассматривать как АПИ. :) Даже конституцию.
ну рефакторинг - отдельная тема, выпускать функционально такой же продукт (но внутренне переработанный!) особого смысла нет, должны быть новые фичи, чтобы пользователь захотел поставить новую версию.
