Что обычно представляют цифры в версии (т.е. v1.9.0.1)?

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

В версии 1.9.0.1 :

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

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

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

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

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

Существует спецификация Semantic Versioning

Это краткое изложение версии 2.0.0:

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

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

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

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

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

MAJOR.MINOR [.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, вы знаете, 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
• второстепенная версия младшего выпуска вашего программного обеспечения, подумайте .NET x.5
• release - выпуск этой версии, обычно исправления ошибок увеличивают это
• build - это число, которое обозначает количество выполненных вами сборок.

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

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

Major.Minor.Bugs

(Или какая-то вариация на это)

Ошибки - это, как правило, исправления ошибок без новой функциональности.

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

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

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

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

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

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

За позицией «3»? Я понятия не имею, почему люди делают такие вещи, это только запутывает.

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

Из файла 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.major.minor.revision было бы моим предположением.
Но это может сильно отличаться между продуктами.

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

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

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

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

Я думаю, что парадигма основного исправления 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. Но он также может содержать номер редакции из вашей системы управления версиями или постоянно увеличивающийся номер, который увеличивается с каждой сборкой. Или Datestamp.

Чуть подробнее здесь . «официально», в .net 4 числа - «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 может содержать версию 1.2.0 Foo и версию 9.5.4 Bar.

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

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. Это число никогда не сбрасывается, а постоянно увеличивается. Используя это, мы всегда можем воссоздать любую версию.

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

версия: v1.9.0.1

где-

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

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

, 9 включает незначительные, будет обновляться о деятельности, такой как добавление новых компонентов, таких как пользовательский интерфейс, API, базы данных и т. Д .; под конкретную архитектуру

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

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