> А можно реальные примеры вашего примера? Желательно со ссылками.Год-два назад я думал, что СемВер решит все мои проблемы, поэтому решил полазать по их багтрекеру. Многие тикеты содержат интересные обсуждения на тему версий и того, насколько СемВер может быть применим в тех или иных условиях. После прочтения всех открытых на тот момент тикетов сложилось общее впечатление о СемВере, однако искать конкретные цитаты сейчас мне некогда.
Если есть желание действительно разобраться в теме, то ОЧЕНЬ советую почитать их багтрекер. Все открытые задачи. Там не так много, за день можно управиться.
Из того, что могу сходу озвучить:
1. Нумерация СемВер основана на понятии совместимости, тогда как нумерация софта традиционно отталкивается от понятий функционала и/или объёма выполненных работ. Это ортогональные понятия.
В случае СемВер изменение версий имеет следующие значение:
- мажорная - изменён/добавлен функционал, пропала совместимость,
- минорная - добавлен функционал, сохранена совместимость,
- патч - функционал не изменён, сохранена совместимость.
В случае софта изменение версий имеет значение (если число компонент версий вообще три):
- мажорная - перед обновлением пользователю рекомендуется тщательно протестировать, всё ли работает, как он ожидает (либо значительно поменялся функционал, либо были переписаны крупные куски кода),
- минорная - добавлен функционал, можно обновиться, если новый функционал нужен, крупных проблем после обновления не возникнет, так как код глобально не переписывался,
- патч - исправлены ошибки, необходимо обновиться, проблем при обновлении не возникнет.
Можно притянуть за уши эти две шкалы, если считать "совместимостью" способность пользователя, работавшего со старой версией, быстро начать работать с новой. Но имхо совместимость - это больше технический, формальный термин, и всегда можно чётко сказать, совместима новая версия со старой или нет. А совместимость "функционала" с точки зрения пользователя оценить может быть сложно, это термин больше психологический, неформальный.
Но даже в этом случае появится несоответствие, когда незначительное изменение рушит "совместимость". Если изменение в софте, то любой адекватный разработчик не станет менять мажорную версию. Хотя по логике СемВер менять нужно именно её.
Мажорная версия в случае СемВер меняется ТОЛЬКО когда ломается совместимость. А в случае версионирования ПО мажорную версию можно менять, например, каждые пять лет просто чтоб продемонстрировать "взрослось" проекта.
Плюс с точки зрения софта, если для исправления мелкой ошибки пришлось значительно поменять какой-то интерфейс или workflow, то меняется патч-версия. Тогда как в случае СемВер, по логике, нужно было бы менять старшую цифру из-за несовместимых изменений.
2. СемВер плохо отражает процесс разработки ПО.
Например, сортировка пререлизных версий идёт по алфавиту. Нам просто повезло, что согласно алфавиту alpha < beta < pre < rc. Но добавьте сюда ещё какую-нибудь стадию, специфичную для вашего проекта, и очень вероятно, что она не впишется в такой порядок.
В СемВер нет пострелизных версий. Вы можете создать 1.0.0-rc.1, но после релиза создать 1.0.0-daily.1 вы не сможете, так как daily будет между beta и pre. Для ежедневных сборок приходится либо использовать 1.0.0+daily.1 (при том, что при сравнении версий метаданные могут игнорироваться), либо нужно угадать, какой будет следующая версия (1.0.1, 1.1.0 или 2.0.0) и дальше делать её пререлизы (1.0.1-daily.1, 1.0.1-daily.2, ...). Если при этом появится функциональное добавление, то после 1.0.1-daily.2 у вас уже будет 1.1.0-daily.1. Это вместо того, чтоб плодить 1.0.0-daily.N а в нужный момент сразу решить, как назвать новую версию.
Тот факт, что любой daily заведомо окажется старше любого beta и младше любого pre (официальная позиция СемВер), не позволяет строить схемы с daily-релизами, местно прерываемыми другими релизами. В СемВер нельзя объявить, что daily невозможно сравнивать с beta/pre.
При нумерации версий софта бывает удобно использовать только две цифры (1.2) или добавить четвёртую (1.2.0.240, например для обозначения номера билда). СемВер недостаточно гибок, чтобы позволить такое.
При создании версии 1.0.0 вы делаете 0.1.0, 0.2.0, 0.3.0... 1.0.0. Но для создания версии 2.0.0 у вас нет такого запаса по числам, приходится изголяться и делать 2.0.0-dev.1.0, 2.0.0-dev.2.0 и т.д. И это описано в самом СемВер, вместо того чтоб запретить всё, начинающееся с нуля, и форсировать схему с 1.0.0-dev.1.0.
Некоторые проекты являются "модификацией" основного проекта. Основной выпускает версию 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, всё же понятно.
3. В багтрекере вообще периодически встречаются комментарии, что СемВер предназначен для разного рода АПИ, и ни для чего другого (правда, я не обращал внимания, комментарии ли это мейнтейнеров СемВера или нет). Если версия вашего софта можно рассматривать как АПИ, то СемВер применим. Но если вы, к примеру, провели масштабный рефакторинг, то ни для пользователя, ни с точки зрения совместимости ничего не поменялось. Однако вы в этом случае можете счесть приемлемым увеличить мажорную версию.
Вариант для распечатки
