Основываясь на моем опыте работы с сложным управлением зависимостью на уровне платформы и выпуском версий на уровне предприятия, я пришел рекомендовать подход, который мне нравится называть Полу Semantic Versioning.
В основном он строится от Semantic Versioning 2.0, но не настолько строг.
Semi-семантическая версия Сегменты:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
первичного сегмент выпуска Формат:
MARKETTING.MAJOR.MINOR.PATCH
Каждый сегмент должен позволить алфавитно-цифровым, но чистые ЦИФРЫ рекомендуется для логических инкрементных изменений.
Как SemVer, я рекомендую Major, Minor и Patch компоненты для представления обратной совместимости русов, но я также рекомендую предваряя компонент маркетинга. Это позволяет владельцам продуктов, функциям эпосов/групп и бизнес-задачам влиять на основной компонент, не зависящий от проблем с технической совместимостью.
В отличие от других ответов, я не рекомендую добавлять номер сборки в основной сегмент.Вместо этого добавьте сегмент в пост-релиз следуя за '+' (например: 1.1.0.0 + build.42). SemVer называет эти метаданные сборки, но я думаю, что пост-релиз-сегмент более ясен. Этот сегмент является большим для объявления данных суффиксов не связаны с информацией о совместимости в сегменте первичного выпуска. После этого вам будет предоставлен предыдущий номер выпуска с добавочным номером сборки, который сбрасывается после каждой первичной версии (например: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Некоторым людям поочередно нравится указывать номер версии svn здесь или git commit sha, чтобы упростить привязку к репозиторию кода. Другой вариант - использовать сегмент пост-релиза для исправлений и исправлений, поэтому стоит рассмотреть возможность добавления для него нового компонента первичной публикации. Он всегда может быть удален, когда компонент патча увеличивается, поскольку версии эффективно выравниваются по левому краю и сортируются.
В дополнение к выпуску и после освобождения сегментов, люди часто хотят использовать сегмент в Pre-Release, чтобы указать почти стабильные предварительные релизы, как альфы, беты и освободить кандидатов. Подход 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 для сложных приложений с множеством небольших независимых версий компонентов (например, микросервисов), каждый из которых имеет свои собственные управляемые зависимости.
Если вы заинтересованы, я написал a semi-semantic parser in ruby. Мне нужно было не просто использовать этот шаблон, но и управлять другими приложениями, которые его использовали.
Через некоторое время, когда вы дойдете до ~ 6 или 7 вы должны переключиться на 2010 (или любой другой хороший год);) – Anonymous
Arg ... Пожалуйста, я прошу вас, не. :-D – DevSolar
http://msdn.microsoft.com/en-us/library/system.version.aspx в замечаниях – Kikaimaru