Как сделать номера версий?

[основная]. [незначительная]. [выпуск]. [сборка]

Major: действительно маркетинговое решение. Вы готовы назвать версию 1.0? Считает ли компания это основной версией, за которую клиентам, возможно, придется платить больше, или это обновление текущей основной версии, которое может быть бесплатным? Меньше решения о НИОКР и больше решения о продукте.

второстепенный: начинается с 0 при увеличении основного. +1 за каждую версию, которая становится общедоступной.

выпуск: каждый раз, когда вы достигаете определенного этапа разработки и выпускаете продукт, даже для внутреннего использования (например, для контроля качества), увеличивайте его. Это особенно важно для общения между командами в организации. Излишне говорить, что никогда не выпускайте один и тот же «релиз» дважды (даже внутри компании). Сброс на 0 при младшем ++ или большом ++.

build: это может быть версия SVN, я считаю, что это работает лучше всего.

Примеры
Мой текущий хром: 83.0.4103.61

x.y.z.g

приращения g нестабильны. (или RC) приращения в z являются стабильными и означают исправления ошибок.
приращения в y стабильны и означают новые функции.
приращения в x являются стабильными, основными выпусками без 100% обратной совместимости.

Однажды я написал подробное «руководство по стилю управления версиями» для своего большого проекта. Проект не был реализован, но руководство по стилю все еще доступно в Интернете. Это мое личное мнение, возможно, оно полезно (или вдохновляет) для вас.

Осторожно, это длинный текст, и он касается управления версиями компонентов и продуктов и тому подобного. Он также выражает твердые мнения о некоторых схемах управления версиями, популярных в сообществе OSS, но они у меня есть, поэтому я их выражаю. ;-)

Я не согласен, например, с использованием номера редакции Subversion. Возможно, вы захотите сохранить выпущенную версию, продолжая разработку в TRUNK, поэтому вы создадите ветку обслуживания - и управление версиями вашего номера ревизии пойдет насмарку.

Изменить: вкратце, в нем проводится различие между управлением версиями исходных файлов, компонентов и всего продукта. Он использует систему отдельных версий x.y для компонентов и продукта с хорошей взаимозависимостью между ними, что делает тривиальным отслеживание того, какая версия компонента какой версии продукта принадлежит. В нем также рассказывается о том, как работать с циклами альфа / бета / выпуска / исправлений, не нарушая работу системы. Фактически, это метод работы для всего цикла разработки, так что вы, возможно, захотите выбрать что-то особенное. ;-)

Редактировать 2: Когда достаточное количество людей сочли мою статью полезной, чтобы сделать ее «Хорошим ответом», я снова начал работать над статьей. Версии PDF и LaTeX уже доступны, полная переработка, включая улучшенный язык и пояснительную графику, последует, как только я найду время. Спасибо за ваши голоса!

Почерпните вдохновение из Википедии: "Управление версиями программного обеспечения"

Другой «новый» и «относительно популярный» вариант - это семантическое управление версиями.

Резюме:

Учитывая номер версии MAJOR.MINOR.PATCH, увеличьте:

1. ОСНОВНАЯ версия при внесении несовместимых изменений API,
2. МИНИМАЛЬНАЯ версия, когда вы добавляете функциональность обратно совместимым образом, и
3. Версия PATCH при исправлении ошибок с обратной совместимостью.

Дополнительные метки для метаданных предварительной версии и сборки доступны как расширения для формата MAJOR.MINOR.PATCH.

a.b.c.d

Приращения: когда
- d: исправление ошибок
- c: обслуживание, например улучшение производительности
- b: новые функции
- a: изменение архитектуры

Обязательный - самый левый, например. если есть, например, новая функция и исправлена ​​ошибка, вам нужно только увеличить b.

Основываясь на моем опыте со сложным управлением зависимостями на уровне корпоративной платформы и управлением версиями, я пришел порекомендовать подход, который я называю Полусемантическое управление версиями.

В основном он основан на семантическом управлении версиями 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 называет эти метаданные сборки, но я думаю, что сегмент пост-релиза более понятен. Этот сегмент отлично подходит для объявления данных суффикса как не связанных с информацией о совместимости в основном сегменте выпуска. Затем вашим сборкам непрерывной интеграции может быть присвоен предыдущий номер выпуска с добавлением номера инкрементной сборки, который сбрасывается после каждого основного выпуска (например: 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 ​​. Мне нужно было не просто использовать этот шаблон, но и уметь управлять другими приложениями, которые его использовали.

«Номера версий» - это вопрос вашей внутренней системы контроля версий. Номера релизов - это другое дело (и их следует СОХРАНИТЬ по-другому).

Придерживайтесь простой системы выпуска MAJOR.MINOR (например, v1.27), где MAJOR - это уровень совместимости (версия 2.x несовместима с версией 1.x или, по крайней мере, сильно отличается от нее), а MINOR - это ваши исправления ошибок или незначительные улучшения. . Если вы следуете формату X.Y, вы также можете использовать другие системы, такие как YEAR.MONTH (2009.12) или YEAR.RELEASE (2009.3). Но на самом деле вам, вероятно, лучше всего придерживаться MAJOR.MINOR, если у вас нет веской причины не делать этого.

Определенно не используйте ничего, что не соответствует формату X.Y, так как это затруднит работу с вами дистрибутивам, сайтам объявлений и т. Д., И это само по себе может серьезно повлиять на популярность вашего проекта.

Используйте ветки и теги в вашей (предпочтительно распределенной) системе управления версиями, чтобы пометить определенные внутренние номера версий как относящиеся к ОСНОВНЫМ и МЕНЬШЕСТВЕННЫМ соответственно.

И да, 1.0 должна быть стабильной. Все выпуски должны быть стабильными, если они не помечены как альфа, бета или RC. Используйте альфа-версии для обозначения заведомо сломанных и неполных. Бета-версии для заведомо-сломанных. RC для «попробуйте; вы, вероятно, заметите то, что мы пропустили». Все, что без одного из них, должно (в идеале, конечно) быть проверено, хорошо известно, иметь обновленное руководство и т. Д.

Схема версий: [major]. [Minor]. [Devrel] [mark]
[major]: приращение, если в процессе разработки произошли резкие изменения.
[minor]: приращение при незначительном изменении в разработке .
[devrel]: увеличивайте, если у вас есть исправленная ошибка. Сбросьте в ноль, если основной ++ или второстепенный ++.
[mark]: a, b или rc: a - это альфа-версия, b - бета-версия, а rc - кандидат на выпуск. Обратите внимание, что такие версии, как 1.3.57a, 1.3.57b или 1.3.57rc, предшествуют версии 1.3.57. Начать с 0.0.0.

В наши дни довольно популярно просто использовать номер версии Subversion.

Если это в SVN, почему бы не использовать номер версии SVN?

Если вы посмотрите в правом нижнем углу этой веб-страницы, вы увидите номер версии Stack Overflow, который является номером версии SVN.

Управление версиями зависит от вас; Я бы поставил 1.0 в первую версию, в которой я был уверен. Возможно, вы захотите быстро дополнить ее другими версиями, поскольку некоторые поставщики программного обеспечения поставили 1.0 плохую репутацию.

Вам действительно нужен способ привязки номера версии к конкретной используемой сборке, но вы, вероятно, хотите, чтобы это было удобно и просто для ваших конечных пользователей. Рассмотрите возможность использования стандартных номеров версий и пометки репозитория SVN включенным номером версии.

Хотя просто указать номер ревизии Subversion приятно и просто, он удаляет информацию из номера версии. Пользователи могут посчитать это плохим.

Я предполагаю, что ваше веб-приложение будет иметь какую-то процедуру развертывания, поэтому не каждая ревизия в Subversion фактически публикуется. Поскольку невозможно "извне" (с точки зрения пользователя) определить, когда выпускаются релизы и сколько изменений будет претерпевать код между ними, это делает числа почти случайными. Они будут увеличиваться, и я предполагаю, что можно предположить некоторое расстояние от сравнения двух ревизий, но не намного.

Классические номера версий имеют тенденцию «драматизировать» выпуски, чтобы пользователи могли строить какие-то ожидания. Легче думать: «У меня версия 1.0, теперь версия 1.1 не добавлена, и это звучит интересно», чем думать: «вчера мы запускали SO, ревизия 2587, сегодня это 3233, должно быть, намного лучше!».

Конечно, эта инсценировка также может быть раздута, поскольку компании выбирают номера версий, которые должны казаться более интересными, чем мотивированные фактическими различиями в продукте, я думаю, использование номера ревизии немного противодействует этому.

Мы потратили слишком много времени на то, чтобы решить, когда увеличивать основную версию. Некоторые магазины редко делают это, поэтому у вас будут выпуски вроде 1.25.3, а другие будут делать это навсегда, давая вам 15.0

Мне это надоело, и я убедил всех, что основной номер выпуска - это только год, а второстепенный - это просто последовательный выпуск в течение года. Пользователям это понравилось, и нетрудно придумать следующий номер версии.

Год.Release.build

• год = текущий год
• release = последовательность # публичных выпусков с новыми функциями - сбрасывается до 1 каждый год
• build = увеличивается для исправлений ошибок и внутренних выпусков

РЕДАКТИРОВАТЬ

** Теперь это было для внутреннего приложения, которое постоянно улучшалось **

Это, вероятно, не сработает для коммерческих приложений, где важно выпускать основные выпуски в разное время года для маркетинговых и финансовых целей.

Причина, по которой существует этот вопрос, заключается в том, что у нас нет единого согласованного способа управления конфигурацией.

Мне нравится делать номер версии, просто увеличивая целое число от 1. Мне не нужен номер версии, состоящий из нескольких частей, который мне придется объяснять или задокументировать. И я не хочу использовать номер версии SVN, так как это также потребует некоторых объяснений.

Для этого вам понадобятся некоторые сценарии выпуска поверх SVN.

У меня очень мало опыта в этой области. Однако вот что я бы сделал:

1. Выберите схему нумерации ревизий и придерживайтесь ее. Быть последовательным.
2. Каждое изменение версии должно означать значительное изменение. Насколько маленькое изменение является значительным, и уровень изменения, который отражается в номере версии, зависит от вас.

Конечно, вы можете просто использовать номер ревизии svn --- как предлагали многие !!!

Надеюсь, это поможет.

Мы используем простой синтаксис major.minor.julian_date.

Где;

• major - первый выпуск равен 1, а затем, когда мы вводим основные новые функции или изменения, настолько существенные, что они не имеют обратной совместимости, увеличивайте это число.
• minor - основные выпуски вехи. Для каждой сборки, запущенной производством, это число увеличивается.
• julian_date - Julian Day, сборка была отправлена ​​в QA.

Пример первого релиза, переданного в QA 1/15: -> 1.0.015
Пример первого релиза, переданного в продакшн 3/4: -> 1.1.063

Это не идеально, но удобно, поскольку мы почти ежедневно отправляем сборки в QA.

Здесь есть полезная информация:

Когда менять версии файла / сборки

Во-первых, версии файлов и сборки могут не совпадать. Я рекомендую менять версии файлов с каждой сборкой. Но не меняйте версии сборки с каждой сборкой только для того, чтобы вы могли различить две версии одного и того же файла; используйте для этого версию файла. Чтобы решить, когда менять версии сборки, необходимо обсудить типы сборок, которые следует учитывать: отгрузка и отгрузка.

Сборки, не предназначенные для доставки В целом, я рекомендую сохранять версии сборок, не предназначенных для доставки, одинаковыми между отправляемыми сборками. Это позволяет избежать проблем с загрузкой сборок со строгими именами из-за несоответствия версий. Некоторые люди предпочитают использовать политику издателя для перенаправления новых версий сборок для каждой сборки. Однако я не рекомендую этого делать для сборок, не поставляемых в продажу: это не позволяет избежать всех проблем с загрузкой. Например, если партнер делает ксерокопирование вашего приложения, он может не знать, что нужно установить политику издателя. Тогда ваше приложение будет сломано для них, даже если оно отлично работает на вашем компьютере.

Но если есть случаи, когда разные приложения на одном компьютере должны быть привязаны к разным версиям вашей сборки, я рекомендую предоставить этим сборкам разные версии сборки, чтобы можно было использовать правильную версию для каждого приложения без использования LoadFrom / etc.

Доставка сборок Что касается того, стоит ли менять эту версию для доставки сборок, это зависит от того, как вы хотите, чтобы привязка работала для конечных пользователей. Вы хотите, чтобы эти сборки располагались бок о бок или на месте? Есть ли много изменений между двумя сборками? Собираются ли они сломать некоторых клиентов? Вам небезразлично, что это их сломает (или вы хотите заставить пользователей использовать ваши важные обновления)? Если да, вам следует рассмотреть возможность увеличения версии сборки. Но, опять же, учтите, что повторение этого слишком много раз может засорять диск пользователя устаревшими сборками.

Когда вы меняете версии сборки Чтобы изменить жестко запрограммированные версии на новую, я рекомендую установить переменную для версии в файле заголовка и заменить жесткое кодирование в источниках на эту переменную. Затем запустите препроцессор во время сборки, чтобы установить правильную версию. Я рекомендую менять версии сразу после доставки, а не прямо перед ним, чтобы было больше времени на обнаружение ошибок, связанных с изменением.

Или использовать номер вашей "мысли" номер версии запятой номер подрывной версии .. z.B .:

1.0.101 // ревизия 101, выпуск

или 1.0.101-090303 // с датой выпуска, я использую это