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

Моя компания строит продукт. Это будет версия от SVN. Это веб-приложение, поэтому, по сути, никогда не будет версии, которая не имеет каких-либо функций и поэтому всегда может быть помечена как бета-версия. Но так как это будет корпоративный продукт, я действительно не хочу, чтобы там были "нестабильные наблюдатели". Так как бы вы занялись версионированием? 1.0 стабильна? Дата сборки должна быть в номере версии? Скажите, что вы, ребята, думаете!

[ Major ]. [ несовершеннолетний ]. [ выпуск ]. [ build ]

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

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

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

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

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

xyzg

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

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

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

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

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

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

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

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

Резюме:

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

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

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

ABCD

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

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

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

По сути, он основан на Semantic Versioning 2.0, но не настолько строг.

Полусемантическая версия Сегменты:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

Основной формат сегмента выпуска:

MARKETTING.MAJOR.MINOR.PATCH

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

Как и SemVer, я рекомендую компоненты Major, Minor и Patch для представления уровней обратной совместимости, но я также рекомендую добавлять компонент Marketing . Это позволяет владельцам продуктов, эпосам / группам функций и бизнес-задачам затрагивать основной компонент независимо от проблем технической совместимости.

В отличие от других ответов, я не рекомендовал добавлять номер сборки в основной сегмент. Вместо этого добавьте сегмент после выпуска, следующий за «+» (например: 1.1.0.0 + build.42). SemVer вызывает эти метаданные сборки, но я думаю, что сегмент Post-Release более ясен. Этот сегмент отлично подходит для объявления данных суффикса как не связанных с информацией о совместимости в основном выпуске., Затем вашим сборкам с непрерывной интеграцией может быть присвоен предыдущий номер выпуска с добавлением добавочного номера сборки, который сбрасывается после каждого основного выпуска (например: 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 - ваши исправления ошибок или незначительные улучшения , Если вы придерживаетесь формата XY, вы также можете использовать другие системы, такие как YEAR.MONTH (2009.12) или YEAR.RELEASE (2009.3). Но на самом деле вам, вероятно, лучше всего придерживаться MAJOR.MINOR, если у вас нет веских причин не делать этого.

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

Используйте ветки и теги в вашей (предпочтительно распределенной) системе контроля версий, чтобы пометить конкретные внутренние номера версий как относящиеся к MAJORS и MINOR соответственно.

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

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

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

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

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

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

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

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

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

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

Схема версий: [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.

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

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

Year.Release.build

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

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

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

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

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

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

Чтобы это произошло, вам понадобятся несколько скриптов релиза поверх SVN.

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

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

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

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

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

Куда;

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

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

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

Немного хорошей информации здесь:

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

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

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

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

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

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

Или использовать ваш «продуманный» номер версии с запятой подрывной деятельности .. zB:

1.0.101 // редакция 101, выпуск

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