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

Ответ 1

[ главная]. [ второстепенный]. [ релиз]. [ построить]

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

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

release. Каждый раз, когда вы наступаете на этап разработки и выпускаете продукт, даже внутренне (например, в QA), увеличивайте это. Это особенно важно для общения между командами в организации. Само собой разумеется, никогда не выпускайте один и тот же "выпуск" дважды (даже внутри). Reset до 0 при младшем ++ или major ++.

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

Ответ 2

x.y.z.g

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

Ответ 3

Однажды я написал сложный "руководство по стилю версии" для крупного проекта. Проект не реализован, но руководство по стилю доступно в Интернете. Это мое личное мнение, возможно, это полезно (или вдохновляет) для вас.

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

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

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

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

Ответ 4

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

Еще одна "новая" и "относительно популярная" опция - Семантическая версия

Резюме:

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

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

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

Ответ 5

Основываясь на моем опыте в области управления зависимостями на уровне платформы на уровне платформы и выпуске версий, я пришел рекомендовать подход, который мне нравится называть Semi-Semantic Versioning.

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

Ответ 6

a.b.c.d

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

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

Ответ 7

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

Ответ 8

"Номера версий" - это вопрос вашей внутренней системы контроля версий. Номера релизов - другое дело (и должны быть KEPT разными).

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

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

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

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

Ответ 9

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

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

Ответ 10

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

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

Ответ 11

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

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

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

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

Ответ 12

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

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

Year.Release.build

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

ИЗМЕНИТЬ

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

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

Ответ 13

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

Ответ 14

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

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

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

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

Ответ 15

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

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

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

Ответ 16

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

Где

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

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

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

Ответ 17

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

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

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

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

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

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

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

Ответ 18

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

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

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