Как сделать номера версий?
https://stackoverflow.com/questions/615227
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Моя компания создает продукт.Его версия будет разрабатываться SVN.Это веб-приложение, поэтому, по сути, никогда не выйдет версия, в которой не было бы некоторых функций и поэтому ее всегда можно было бы пометить как бета-версию.Но поскольку это будет корпоративный продукт, я действительно не хочу, чтобы там было «нестабильное предупреждение».Итак, как бы вы поступили с версией?Версия 1.0 стабильна?Должна ли дата сборки быть в номере версии?Скажите мне, что вы думаете, ребята!
Решение
[главный].[незначительный].[выпускать].[строить]
главный:Действительно маркетинговое решение.Вы готовы назвать версию 1.0?Считает ли компания это основной версией, за которую клиентам, возможно, придется платить больше, или это обновление текущей основной версии, которое может быть бесплатным?В меньшей степени это решение по исследованиям и разработкам, а в большей — решение по продукту.
незначительный:Начинается с 0 всякий раз, когда главный увеличивается.+1 за каждую опубликованную версию.
выпускать:Каждый раз, когда вы достигаете определенного этапа разработки и выпускаете продукт, даже внутри компании (например,в QA), увеличьте это.Это особенно важно для коммуникации между командами в организации.Излишне говорить, что никогда не выпускайте один и тот же «релиз» дважды (даже внутри компании).Сброс в 0 при минорном++ или мажорном++.
строить:Это может быть версия SVN, я считаю, что она работает лучше всего.
Другие советы
x.y.z.g
приращения g нестабильны.(или RCS) Приращение Z является стабильным и средним исправлением ошибок.
приращения y стабильны и означают новые функции.
приращения x стабильны, основной выпуск без 100% обратной совместимости.
Однажды я написал подробное «руководство по стилю управления версиями». для большого проекта моего. Проект не был реализован, но руководство по стилю по-прежнему доступно в Интернете . Это мое личное мнение, возможно, оно полезно (или вдохновляет) для вас.
Осторожно, это длинный текст, посвященный управлению версиями компонентов по сравнению с версиями продуктов и тому подобному. Он также выражает твердое мнение о некоторых схемах управления версиями, популярных в сообществе OSS, но у меня они есть, поэтому я выражаю их. ; -)
Я не согласен с использованием, например, номера редакции Subversion. Возможно, вы захотите сохранить выпущенную версию, продолжая разработку в TRUNK, поэтому вы создадите ветку обслуживания - и версия вашего номера ревизии полностью исчезнет.
Редактировать . В качестве краткого изложения различаются исходные файлы, компоненты и продукт в целом. Он использует систему отдельного x.y-версинга для компонентов и продукта, с хорошей взаимозависимостью между этими двумя компонентами, что делает отслеживание, какая версия компонента принадлежит какой версии продукта. В нем также говорится о том, как обрабатывать циклы альфа / бета / релиз / патч, не нарушая систему. На самом деле, это способ работы для всего цикла разработки, так что вы можете выбрать вишню. ; -)
Изменить 2 . Поскольку многие люди сочли мою статью полезной, чтобы сделать ее "Хорошим ответом", я снова начал работать над этой статьей. Доступны версии PDF и LaTeX, полное переписывание, включая улучшенный язык и пояснительную графику, последует, как только я найду время. Спасибо за ваши голоса!
Черпайте вдохновение из Википедии: «Версии программного обеспечения»
Еще один «новый» и «относительно популярный» вариант — Семантическое управление версиями
Краткое содержание:
Учитывая номер версии MAJOR.MINOR.PATCH, увеличьте:
- ОСНОВНАЯ версия, когда вы вносите несовместимые изменения API,
- МИНОРНАЯ версия, когда вы добавляете функциональность с обратной совместимостью, и
- PATCH-версия, когда вы исправляете ошибки с обратной совместимостью.
Дополнительные этикетки для метаданных предварительных выпусков и сборки доступны в качестве расширений в формате major.minor.patch.
а.б.к.д.
Приращения:когда
- д:исправление ошибок
- с:техническое обслуживание, напримерулучшение производительности
- б:новые возможности
- а:изменение архитектуры
Обязательным является самый левый, например.если, например, появилась новая функция и исправлена ошибка, вам нужно только увеличить б.
Основываясь на моем опыте работы со сложным управлением зависимостями на уровне корпоративной платформы и управлением версиями выпусков, я решил порекомендовать подход, который мне нравится называть Полусемантическое управление версиями.
В основном он строится на Семантическое управление версиями 2.0 но не так строго.
Сегменты полусемантической версии:
<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]
Формат сегмента основного выпуска:
МАРКЕТИНГ.БОЛЬШОЙ.МИНОРНЫЙ.ПАТЧ
Каждый сегмент должен допускать использование буквенно-цифровых символов, но для логических дополнительных изменений рекомендуется использовать чистые цифры.
Как и СемВер, рекомендую Компоненты Major, Minor и Patch для представления уровней обратной совместимости, но я также рекомендую добавить перед Маркетинговая составляющая.Это позволяет владельцам продуктов, эпопеям/группам функций и бизнес-задачам добавлять основной компонент независимо от проблем технической совместимости.
В отличие от других ответов, я не рекомендую добавлять номер сборки к основному сегменту.Вместо этого добавьте Пост-релизный сегмент после '+' (например:1.1.0.0+сборка.42).SemVer называет это метаданными сборки, но я думаю, что сегмент после выпуска более понятен.Этот сегмент отлично подходит для объявления данных суффикса как не связанных с информацией о совместимости в основном Сегмент выпуска.Затем вашим сборкам непрерывной интеграции может быть присвоен номер предыдущей версии, к которому добавляется инкрементальный номер сборки, который сбрасывается после каждого основного выпуска (например:1.1.0.0 -> 1.1.0.0+сборка.1 -> 1.1.0.0+сборка.2 -> 1.1.0.1 ).Некоторым людям поочередно нравится помещать здесь номер версии svn или git commit sha, чтобы упростить привязку к репозиторию кода.Другой вариант — использовать сегмент после выпуска для исправлений и исправлений, хотя, возможно, стоит рассмотреть возможность добавления для этого нового основного компонента выпуска.Его всегда можно удалить при увеличении компонента исправления, поскольку версии фактически выравниваются по левому краю и сортируются.
Помимо сегментов релиза и пост-релиза, люди часто хотят использовать Предварительный сегмент для обозначения почти стабильных предварительных выпусков, таких как альфа-версии, бета-версии и кандидаты на выпуск.Подход SemVer работает хорошо, но я рекомендую отделять числовые компоненты от буквенно-цифровых классификаторов (например:1.2.0.0+альфа.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, вы также можете использовать другие системы, такие как ГОД.МЕСЯЦ (2009.12) или ГОД.РЕЛИЗ (2009.3).Но на самом деле вам, вероятно, лучше придерживаться MAJOR.MINOR, если у вас нет веской причины не делать этого.
Определенно не используйте ничего, что не соответствует формату XY, так как это затруднит работу дистрибутивов, веб-сайтов объявлений и т. д.работать с вами, и уже одно это может серьезно повлиять на популярность вашего проекта.
Используйте ветки и теги в вашей (желательно распределенной) системе контроля версий, чтобы пометить определенные внутренние номера версий как относящиеся к MAJORS и MINORS соответственно.
И да, 1.0 должна быть стабильной.Все выпуски должны быть стабильными, если только они не отмечены пометкой «альфа», «бета» или «RC».Используйте Alpha для известных испорченных и неполных.Беты для известных-сломанных.RC для «попробуй;вы, вероятно, заметите то, что мы пропустили».Все, что не имеет ни одного из них, должно (в идеале, конечно) быть протестировано, заведомо исправно, иметь обновленное руководство и т. д.
В наши дни довольно популярно просто использовать номер ревизии Subversion.
Если это в SVN, то почему бы не использовать номер редакции SVN?
Если вы посмотрите в правом нижнем углу этой веб-страницы, вы увидите номер версии переполнения стека, который является номером версии SVN.
Управление версиями зависит от вас; Я бы поставил 1.0 на первую версию, в которой я был уверен. Возможно, вы захотите быстро продолжить ее с другими версиями, поскольку некоторые поставщики программного обеспечения дали 1.0 плохую репутацию.
Вы хотите каким-то образом связать номер версии с точной используемой сборкой, но вы, вероятно, хотите, чтобы он был приятным и простым для конечных пользователей. Попробуйте использовать стандартные номера версий и пометить SVN-репозиторий включенным номером версии.
Хотя просто использовать номер версии Subversion приятно и просто, он удаляет информацию из номера версии.Пользователи могут посчитать это плохим.
Я предполагаю, что в вашем веб-приложении будет какая-то процедура развертывания, поэтому не каждая редакция Subversion будет фактически опубликована.Поскольку невозможно «извне» (с точки зрения пользователя) определить, когда выходят релизы, и сколько ревизий код претерпит между ними, это делает числа практически случайными.Они будут увеличиваться, и я думаю, можно предположить. некоторый какая-то дистанция от сравнения двух ревизий, но не большая.
Классические номера версий имеют тенденцию «драматизировать» выпуски, чтобы пользователи могли строить какие-то ожидания.Легче думать: «У меня есть версия 1.0, сейчас вышла версия 1.1, в которую добавлено то и это, это звучит интересно», чем думать: «Вчера мы запускали SO-версию 2587, сегодня — 3233, должно быть, она намного лучше!».
Конечно, эта драматизация также может быть раздута: компании выбирают номера версий, которые должны звучать более интересно, чем мотивированы фактическими различиями в продукте, я думаю, это немного связано со счетчиками номеров ревизий.
Схема версий: [Major]. [несовершеннолетний]. [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.
Мне это надоело, и я убедил всех, что номер основного выпуска — это просто год, а второстепенный — это просто последовательный выпуск в течение года.Похоже, пользователям это понравилось, и им не составило труда придумать номер следующей версии.
Год.Выпуска.сборки
- год = текущий год
- Release = последовательность публичных выпусков с новой функциональностью - сброс до 1 каждый год
- Build = увеличение для исправлений ошибок и внутренних выпусков
РЕДАКТИРОВАТЬ
** Это было внутреннее приложение, которое постоянно улучшалось **
Вероятно, это не сработает для коммерческих приложений, где для маркетинговых и финансовых целей важно выпускать основные выпуски в разное время года.
У меня очень мало опыта в этой области. Однако вот что я сделаю:
<Ол>Конечно, вы можете просто использовать номер редакции svn - как и многие другие предлагали !!!
Надеюсь, это поможет.
Причина, по которой этот вопрос существует, заключается в том, что у нас нет единого согласованного способа управления конфигурацией.
Мне нравится делать номер версии, просто увеличивая число на 1. Я не хочу, чтобы номер версии состоял из нескольких частей, которые мне придется объяснить или задокументировать. И я не хочу использовать номер версии SVN, поскольку это также потребует некоторых пояснений.
Чтобы это произошло, вам понадобятся некоторые сценарии выпуска поверх SVN.
Мы используем простой синтаксис major.minor.julian_date.
Где;
- основной — первый выпуск равен 1, а затем, когда мы вводим важные новые функции или изменения, настолько существенные, что они не имеют обратной совместимости, увеличивают это число.
- второстепенный — основные выпуски.С каждой новой сборкой это число увеличивается.
- julian_date — Джулиан Дэй сборка была передана в отдел контроля качества.
Пример первого релиза, отправленного на проверку качества 15 января: -> 1.0.015.
Пример первого релиза, отправленного в производство 3/4: -> 1.1.063.
Это не идеально, но удобно, поскольку мы практически ежедневно отправляем сборки на проверку качества.
Хорошая информация здесь:
Когда менять версии файла / сборки
Прежде всего, версии файлов и версии сборок не обязательно должны совпадать. Я рекомендую, чтобы версии файлов менялись с каждой сборкой. Но не меняйте версии сборок с каждой сборкой, чтобы вы могли увидеть разницу между двумя версиями одного и того же файла; используйте версию файла для этого. Решение о том, когда менять версию сборки, требует некоторого обсуждения типов сборок, которые следует учитывать: доставка и не доставка.
Сборки без доставки В целом, я рекомендую сохранять версии сборок, не относящихся к отправке, одинаковыми между сборками. Это позволяет избежать проблем с загрузкой сборок со строгими именами из-за несоответствия версий. Некоторые люди предпочитают использовать политику издателя для перенаправления новых версий сборок для каждой сборки. Тем не менее, я рекомендую использовать это для сборок, не предназначенных для доставки: это не позволяет избежать всех проблем с загрузкой. Например, если партнер ксерокопирует ваше приложение, он может не знать, как установить политику издателя. Тогда ваше приложение будет сломано для них, даже если оно отлично работает на вашем компьютере.
Но если есть случаи, когда разные приложения на одном компьютере должны привязываться к разным версиям вашей сборки, я рекомендую давать этим сборкам разные версии сборки, чтобы можно было использовать правильную версию для каждого приложения без использования LoadFrom. / др.
Транспортные сборки Что касается того, будет ли хорошей идеей изменить эту версию для доставки сборок, это зависит от того, как вы хотите, чтобы привязка работала для конечных пользователей. Вы хотите, чтобы эти сборки были рядом или на месте? Много ли изменений между двумя сборками? Они собираются сломать некоторых клиентов? Вы заботитесь о том, чтобы это сломало их (или вы хотите заставить пользователей использовать ваши важные обновления)? Если да, вам следует рассмотреть возможность увеличения версии сборки. Но, опять же, учтите, что выполнение этого слишком много раз может засорить пользовательский диск устаревшими сборками.
Когда вы меняете версии сборки Чтобы заменить жестко закодированные версии на новые, я рекомендую установить переменную в версию в заголовочном файле и заменить жесткое кодирование в источниках переменной. Затем запустите препроцессор во время сборки, чтобы установить правильную версию. Я рекомендую менять версии сразу после доставки, а не прямо перед этим, чтобы у вас было больше времени для выявления ошибок из-за изменений.
Или использовать ваш «продуманный» номер версии с запятой подрывной деятельности. z.B:.
1.0.101 // редакция 101, выпуск
или 1.0.101-090303 // с датой выпуска, я использую это
