Comments 13
Четко и по сути. Благодарю.
Сейчас набирает аопулярность другой принцип нумерации версий, опирающийся на год выпуска. Вторая цифра означает либо месяц, либо номер какой-то части года (полугодие, квартал), либо порядковый номер версии в течении года.
Используется, например, в Libreoffice и 7-zip.
Уже и до библиотек этот способ добрался (lzma)
Как правило такой способ используется для приложений, которые не создают ни какие артефакты или формат этих артефактов не зависит от версии приложения. Например формат odt, 7-zip и др. определяется отдельной спецификацией, которую не может изменить автор(ы) приложения.
В случае с библиотеками это скорее исключение. Надо быть очень уверенным в том, что API библиотеки не поменяется никогда в будущем. Чаще такое можно сказать про "заброшенные" библиотеки, в которых только исправляют ошибки и поддерживают "на плаву".
Надо быть очень уверенным в том, что API библиотеки не поменяется никогда в будущем.
API библиотеки, пригодной к использованию, не может меняться в обе стороны, только в сторону расширения. Обратная совместимость — наиглавнейший параметр при любом изменении. Если библиотека не совместима с предыдущими версиями — место ей в мусорном ведре.
Это слишком радикально.
Правильнее вот так: Если автор сломал обратную совместимость - это его дело, вероятно так будет лучше. Но если он при этом не продолжает исправлять критические ошибки в прошлой версии - место ему в мусорном ведре :-)
Ладно, так тоже нормально :)
Но это еще менее реалистично, чем поддерживать обратную совместимость — как автор и мейнтейнер 10+ библиотек говорю. В принципе, еще туда-сюда поломать API при выходе из мажорной версии 0 в 1 (хотя я себе и такое не позволяю).
Но выше — ёлки-палки, это не так сложно, подумать вон о том Васе, который хочет новые плюшки, но не может проапгрейдить весь мир по не зависящим от него причинам.
Из-за такой мотивации кучу библиотек десятилетиями не вылазят из версии 0.х. Всё думают про Васю, который может очень расстроится если через год после версии 1.0 выйдет версия 2.0. Лучше уж дождаться момента, когда просто не захочется или не будет возможности вносить улучшения в библиотеку. Тогда и выпустить 1.0.
Например формат odt, 7-zip и др. определяется отдельной спецификацией, которую не может изменить автор(ы) приложения.
Если спкцификация формата изменяется (новые версии форматов - не такая уж и редкостъ), то приложение (и библиотеки, работаюшие с фвйлами данного формата) вынуждены расширять свои возможности для реализации новых фишек формата.
В случае 7z уже достигнутв ситуация, когда сиарые версии архиватора не всегда могут открыть файл, созданный новой версией арзиватора (появился новый алгоритм сжатия - LZMA2)
Описанный вами подход называется calver — Calendar Versioning. В статье рассматривается semver — Semantic Versioning.
Я использую calver в приложениях, потому что клиентам не важно знать, ломается обратная совместимость или нет.
В библиотеках обратная ситуация: важно понимать, сломается ли обратная совместимость при обновлении, а вместе с ней — и полпроекта. Semver даёт такое понимание, но в реальности всё зависит от ответственности разработчика библиотеки.
Хорошо бы добавить TL DR или подитог, чтобы кратко определить рекомендацию к различиям между версиями.
Если кратко. Версия, вообще говоря, состоит из четырёх чисел, например: 1.2.3.4
Эти числа носят следующие названия в порядке слева направо: 1 - Major number, 2 - Minor number, 3 - Patch number, 4 - Build number.
Если отличается Major, то это означает наиболее радикальные отличия. Либо формат данных полностью изменился, либо полностью изменился пользовательский интерфейс. В общем, на новую программу придётся полностью переучиваться.
Если отличается Minor, то это, как правило, означает лишь расширение функционала существующей программы. Формат данных дополнился новыми полями, в интерфейсе пользователя появились новые пункты меню, новые виджеты. Однако пользователь, знакомый с предыдущей версией, без труда разберётся с новой, так как версии схожи между собой.
Если отличается Patch number, то это означает исправление ошибок в программе, без изменения интерфейса.
Последний - Build number, используется только разработчиком программы, например так: программист создаёт программу, присваивает ей очередной этот номер, затем программу проверяют на ошибки, если обнаруживают, то исправляют, и присваивают следующий номер. Либо добавляют функционал, и тоже увеличивают этот номер. Но все эти циклы происходят внутри компании, и чтобы не сбивать с толку конечных пользователей, изменения пишут в этот номер, чтобы потом, при распространении программы, просто его убрать.
Вообще говоря, запись версии через точку оказалась неудачной идеей, так как создаёт путаницу с записью вещественных чисел. В результате, возникает неопределённость, какой номер версии более новый: 1.2 или 1.101
Каждая компания интерпретирует это по-своему.
Благодарю. Примерно этого я хотел добиться от автора, чтобы он добавил в пост. И читающим, не знакомым с темой, было проще понять.
PS. У нас в компании при разработке софта используются примерно те же правила нумерации.
При разработке документации правила следующие:
- Major версия - изменение набора функционала, который не имеет обратной совместимости с предыдущей версией.
- Minor версия - добавление новых методов или параметров, при этом обратная совместимость сохраняется.
- Fix версия - смысловых изменений нет, исправления в основном носят редакционный характер (добавляется/расширяется описание, появляются уточнения).
О чем говорит версия проекта?