Что обычно обозначают числа в версии (например, v1.9.0.1)?

В версии 1.9.0.1:

• 1: основные изменения (новый пользовательский интерфейс, множество новых функций, концептуальные изменения и т. д.)

• 9: незначительное изменение (возможно, изменение окна поиска, добавление 1 функции, сборник исправлений ошибок)

• 0: выпуск с исправлением ошибки

• 1: номер сборки (если используется) - поэтому вы видите, что платформа .NET использует что-то вроде 2.0.4.2709.

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

Существует спецификация семантического управления версиями

Это сводка версии 2.0.0:

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

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

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

Он может быть очень произвольным и различается от продукта к продукту. Например, в дистрибутиве Ubuntu 8.04 относится к апрелю 2008 года.

Обычно крайние левые (основные) числа указывают на основную версию, и чем дальше вы идете вправо, тем меньшие изменения вносятся.

major.minor [.main maintenance [.build]]

http://en.wikipedia.org/wiki/Software_versioning#Numeric

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

WordPress, например, работает в этом направлении:

1.6 -> 2.0 -> 2.0.1 -> 2.0.2 -> 2.1 -> 2.1.1 -> 2.2 ...

1.6–2.0 будет большим выпуском - функции, изменения интерфейса, серьезные изменения API, поломка некоторых шаблонов и плагинов 1.6 и т. Д. 2.0–2.0.1 будет второстепенным выпуском - возможно, исправляющим ошибку безопасности. 2.0.2–2.1 будет значительным выпуском - как правило, новыми функциями.

Числа могут быть полезны, как описано в других ответах, но подумайте, как они могут быть довольно бессмысленными ... Солнце, вы знаете, SUN, java: 1.2, 1.3, 1.4 1.5 или 5, затем 6. В старом добром Apple II номера версий имели в виду Что-то. В настоящее время люди отказываются от номеров версий и пользуются глупыми именами, такими как «Feisty fig» (или что-то в этом роде), «hardy heron», «europa» и «ganymede». Конечно, это гораздо менее полезно, потому что у вас закончатся луны Юпитера до того, как вы перестанете менять программу, а поскольку нет очевидного порядка, вы не можете сказать, какая из них новее.

В версии v1.9.0.1: Это явная схема управления версиями, используемая, когда вы не хотите использовать имя для предварительных выпусков или сборки, например -alpha, -beta.

1: Основная версия, которая может нарушить обратную совместимость

9: Добавление новых функций для поддержки вашего приложения вместе с обратной совместимостью с предыдущей версией.

0: Исправлены незначительные ошибки.

1: Номер сборки (номер предварительной версии)

но в настоящее время вы не найдете такой схемы управления версиями. Обратитесь к Семантическому управлению версиями [semver2.0] https://semver.org/

Номера версий обычно не представляют собой отдельные компоненты. Для некоторых людей / программного обеспечения цифры довольно произвольны. Для других разные части строки номера версии действительно представляют разные вещи. Например, в некоторых системах части номера версии увеличиваются при изменении формата файла. Таким образом, V 1.2.1 - это формат файла, совместимый со всеми другими версиями V 1.2 (1.2.2, 1.2.3 и т. Д.), Но не с V 1.3. В конечном итоге вам решать, какую схему вы хотите использовать.

Обычно это:

MajorVersion.MinorVersion.Revision.Build

Это зависит от обстоятельств, но обычно это major.minor.release.build.

Где:

• major - это основная версия вашего программного обеспечения, например .NET 3.x
• minor - это дополнительная версия вашего программного обеспечения, например .NET x.5.
• release - это выпуск этой версии, обычно исправления ошибок увеличивают этот
• build - это число, обозначающее количество выполненных сборок.

Так, например, 1.9.0.1 означает, что это версия 1.9 вашего программного обеспечения, следующая за 1.8 и 1.7 и т. Д., Где 1.7, 1.8 и 1.9 все так или иначе обычно добавляют небольшое количество новых функций наряду с исправлениями. Поскольку это x.x.0.x, это начальный выпуск 1.9 и первая сборка этой версии.

Вы также можете найти полезную информацию в статье Википедии по этой теме.

Major.Minor Bugs

(Или какой-то вариант этого)

Ошибки обычно представляют собой исправления ошибок без каких-либо новых функций.

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

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

Каждый выбирает, что ему делать с этими числами. У меня возникло искушение назвать релизы a.b.c, так как в любом случае это довольно глупо. При этом то, что я видел за последние 25 с лишним лет разработки, имеет тенденцию работать именно так. Допустим, у вас номер версии 1.2.3.

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

Цифра «2» указывает на выпуск в серии. Часто мы используем эту позицию, чтобы узнать о функциях, которых не было в последней крупной версии. Эта позиция (2) почти всегда указывает на добавление функции, обычно с исправлением ошибок.

Цифра «3» в большинстве магазинов означает выпуск патча / исправление ошибки. Практически никогда, по крайней мере, с коммерческой точки зрения, это не указывает на добавление важных функций. Если функции появляются в позиции 3, то это, вероятно, потому, что кто-то что-то проверил до того, как мы узнали, что нам нужно выпустить выпуск с исправлением ошибок.

За пределами "3" позиции? Я понятия не имею, почему люди делают такие вещи, это только сбивает с толку.

Примечательно, что некоторые из OSS выбрасывают все это из дурака. Например, Trac версии 10 на самом деле 0.10.X.X. Я думаю, что многие люди в мире OSS либо не уверены в себе, либо просто не хотят объявлять о том, что у них есть крупный релиз.

release.major.minor.revision, как я предполагаю.
Но он может сильно различаться в зависимости от продукта.

Major.minor.point. строят обычно. Major и minor не требуют пояснений, point - это выпуск с несколькими незначительными исправлениями, а build - это просто идентификатор сборки.

Ага. Основные выпуски добавляют большие новые функции, могут нарушать совместимость или иметь существенно разные зависимости и т. Д.

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

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

Из файла C # AssemblyInfo.cs вы можете увидеть следующее:

// Version information for an assembly consists of the following four values:
//
//      Major Version
//      Minor Version 
//      Build Number
//      Revision
//
/ You can specify all the values or you can default the Build and Revision Numbers 
// by using the '*' as shown below:
// [assembly: AssemblyVersion("1.0.*")]

Я думаю, что парадигма основного исправления release.minor release.bug довольно распространена.

В некоторых контрактах на поддержку предприятия есть $$$ (или нарушение обязательств по контракту), связанное с тем, как обозначен конкретный выпуск. Контракт, например, может давать клиенту право на некоторое количество основных выпусков за определенный период времени, или обещать, что будет меньше чем x количество второстепенных выпусков за период, или что поддержка будет по-прежнему доступна для такого количества выпускает. Конечно, независимо от того, сколько слов добавлено в контракт, чтобы объяснить, что такое основной выпуск по сравнению с второстепенным, это всегда субъективно, и всегда будут присутствовать серые зоны, ведущие к вероятности того, что поставщик программного обеспечения может сыграть в систему. превзойти такие договорные положения.

Люди не всегда замечают тонкую разницу между номерами версий, такими как 2.1, 2.0.1 или 2.10 - спросите у специалиста службы поддержки, сколько раз у них были проблемы с этим. Разработчики ориентированы на детали и знакомы с иерархическими структурами, поэтому для нас это слепое пятно.

Если возможно, предложите клиентам более простой номер версии.

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

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

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

Основные номера версий могут нарушить все три формы.

Подробнее об обосновании я написал здесь.

Комбинация основных, второстепенных, исправлений, сборок, исправлений безопасности и т. Д.

Первые два - основные и второстепенные - остальные будут зависеть от проекта, компании, а иногда и сообщества. В таких ОС, как FreeBSD, у вас будет номер 1.9.0.1_number для обозначения исправления безопасности.

Немного зависит от языка, например, Delphi и C # имеют разные значения.

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

Третье число может относиться к «действительно минорной» версии или ревизии. 1.0.1 - это, например, очень небольшое исправление для 1.0.0. Но он также может содержать номер версии из вашей системы управления версиями или постоянно увеличивающийся номер, который увеличивается с каждой сборкой. Или отметку даты.

Немного подробнее здесь. "официально" в .net четыре числа - это "Major.Minor.Build.Revision", тогда как в Delphi это "Major.Minor.Release.Build". Я использую Major.Minor.ReallyMinor.SubversionRev для управления версиями.

Обычно номера имеют формат version.major.minor.hotfix, а не отдельные внутренние компоненты. Таким образом, v1.9.0.1 будет версией 1, основным выпуском 9 (v1), второстепенным выпуском (v1.9) 0, оперативным исправлением 1 (v1.9.0).

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

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

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

Последний номер - это обычно номер редакции. Часто это используется в процессе автоматической сборки или когда вы делаете «одноразовые» одноразовые сборки для тестирования.

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

Номер версии сложного программного обеспечения представляет собой весь пакет и не зависит от номеров версий частей. Версия Gizmo 3.2.5 может содержать Foo версии 1.2.0 и Bar версии 9.5.4.

При создании номеров версий используйте их следующим образом:

1. Первый номер - основной выпуск. Если вы вносите существенные изменения в пользовательский интерфейс или вам нужно сломать существующие интерфейсы (так, чтобы вашим пользователям пришлось изменить свой код интерфейса), вам следует перейти на новую основную версию.

2. Второй номер должен указывать на то, что были добавлены новые функции или что-то работает по-другому внутри. (Например, база данных Oracle может решить использовать другую стратегию для извлечения данных, делая большую часть работы быстрее, а некоторые - медленнее.) Существующие интерфейсы должны продолжать работать, а пользовательский интерфейс должен быть узнаваемым.

3. Дальнейшая нумерация версий зависит от человека, пишущего программное обеспечение - Oracle использует пять (!) Групп, т.е. версия Oracle - это что-то вроде 10.1.3.0.5. Начиная с третьей группы и ниже, вы должны вносить только исправления или незначительные изменения в функциональности.

те, которые различаются меньше, будут первыми двумя, для major.minor, после этого это может быть что угодно: от сборки, ревизии, выпуска до любых пользовательских алгоритмов (например, в некоторых продуктах MS)

У каждой организации / группы есть свои стандарты. Важно то, что вы придерживаетесь того обозначения, которое выберете, иначе ваши клиенты будут сбиты с толку. Сказав, что я обычно использовал 3 числа:

x.yz.bbbbb. Где: x: - основная версия (основные новые функции) y: - это дополнительный номер версии (небольшие новые функции, небольшие улучшения без изменений пользовательского интерфейса) z: - это пакет обновления (в основном такой же, как xy, но с некоторыми исправлениями ошибок bbbb: - это номер сборки, который действительно виден только из окна «Информация» вместе с другими деталями для поддержки клиентов. bbbb - это бесплатный формат, и каждый продукт может использовать его собственный.

Вот что мы используем:

1. Первое число = общая эпоха системы. Меняется каждые пару лет и обычно представляет собой фундаментальное изменение технологии или клиентских функций, либо того и другого.
2. Второе число = версия схемы базы данных. Увеличение этого числа требует миграции базы данных и, следовательно, является значительным изменением (или системы реплицируются, поэтому изменение структуры базы данных требует тщательного процесса обновления). Сбрасывается в 0 при изменении первого числа.
3. Третье число = изменение только программного обеспечения. Обычно это может быть реализовано от клиента к клиенту, поскольку схема базы данных не изменяется. Сбрасывается в ноль при изменении второго числа.
4. Номер версии Subversion. Мы заполняем его автоматически при сборке с помощью инструмента TortoiseSVN. Это число никогда не сбрасывается, а постоянно увеличивается. Используя это, мы всегда можем воссоздать любую версию.

Эта система хорошо нам служит, потому что у каждого номера есть четкая и важная функция. Я видел, как другие команды борются с вопросом о главном / второстепенном числе (насколько большое изменение является основным), и я не вижу в этом пользы. Если вам не нужно отслеживать изменения в базе данных, просто выберите номер версии из 3 или 2 цифр и упростите жизнь!

версия: v1.9.0.1

куда-

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

. 1 указывает основную версию, будет обновляться при изменении архитектуры в стеках приложений, инфраструктуре (платформе) или открытом сетевом интерфейсе

. 9 incates minor, будет обновляться при таких действиях, как добавление новых компонентов, таких как ui, api, database и т. Д .; под специфической архитектурой

. 0 указывает на функцию, будет обновляться при любых улучшениях в существующих компонентах (пользовательский интерфейс, API, база данных и т. Д.)

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