Основываясь на своем опыте со сложным управлением зависимостями на уровне корпоративной платформы и версиями версий, я рекомендовал подход, который мне нравится называть Полусемантическое управление версиями .
В основном он основан на Semantic Versioning 2.0 , но не настолько строг.
Сегменты полусемантической версии:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
Основной формат сегмента выпуска:
MARKETTING.MAJOR.MINOR.PATCH
В каждом сегменте должны быть разрешены алфавитно-цифровые символы, но для логических инкрементальных изменений рекомендуются чистые цифры.
Как и SemVer, я рекомендую Major, Minor и Patch компоненты для представления уровней обратной совместимости, но я также рекомендую добавлять Маркетинговый компонент . Это позволяет владельцам продуктов, тематическим эпосам / группам и бизнес-задачам затрагивать основной компонент независимо от проблем технической совместимости.
В отличие от других ответов, я не рекомендовал добавлять номер сборки в основной сегмент. Вместо этого добавьте Сегмент после релиза после '+' (например: 1.1.0.0 + build.42). SemVer вызывает эти метаданные сборки, но я думаю, что сегмент Post-Release более ясен. Этот сегмент отлично подходит для объявления данных суффикса как не связанных с информацией о совместимости в первичном Release Segment . Затем вашим сборкам с непрерывной интеграцией может быть присвоен предыдущий номер выпуска с добавлением добавочного номера сборки, который сбрасывается после каждого основного выпуска (например: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Некоторым людям поочередно нравится указывать здесь номер ревизии svn или git commit sha, чтобы упростить привязку к репозиторию кода. Другим вариантом является использование сегмента пост-релиза для исправлений и исправлений, хотя, возможно, стоит подумать о добавлении для этого нового основного компонента выпуска. Он всегда может быть отброшен при увеличении компонента исправления, поскольку версии эффективно выровнены по левому краю и отсортированы.
Помимо сегментов выпуска и пост-релиза, люди часто хотят использовать сегмент предварительного релиза для обозначения почти стабильных предварительных выпусков, таких как альфа, бета-версии и кандидаты на релиз. Подход SemVer к этому хорошо работает, но я рекомендую отделить числовые компоненты от буквенно-числовых классификаторов (например: 1.2.0.0 + alpha.2 или 1.2.0.0 + RC.2). Обычно вы производите удар по сегменту релиза одновременно с добавлением сегмента после релиза, а затем отбрасываете сегмент до релиза при следующем увеличении сегмента основного релиза (например: 1.0.1.2 -> 1.2.0.0-RC.1 - > 1.2.0.0). Предварительно выпущенные сегменты добавляются, чтобы указать, что готовится к выпуску версия, обычно это просто фиксированный набор функций для более глубокого тестирования и совместного использования, который не меняется от минуты к минуте при большем количестве коммитов.
Прелесть того, что все это семантически определено таким образом, что охватывает почти все варианты использования, состоит в том, что вы можете анализировать, сортировать, сравнивать и увеличивать их стандартным образом. Это особенно важно, когда использование систем CI для сложных приложений с множеством небольших независимых версий компонентов (например, микро-сервисов), каждый из которых имеет свои управляемые зависимости.
Если вам интересно, я написал полусемантический парсер в ruby . Мне нужно было не просто использовать этот шаблон, но и иметь возможность управлять другими приложениями, которые его использовали.