Что типично представляют номера в версии (т.е. V1.9.0.1)?

Ответ 1

В версии 1.9.0.1:

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

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

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

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

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

Ответ 2

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

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

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

MAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.

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

Ответ 3

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

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

Ответ 4

MAJOR.MINOR [.maintenance [.build]]

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

Ответ 5

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

Ответ 6

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

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 будет значительным выпуском - новые функции, как правило.

Ответ 7

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

Проверьте эти ресурсы:
http://www.netbeans.org/community/guidelines/process.html
http://en.wikipedia.org/wiki/Release_engineering
http://www.freebsd.org/releases/6.0R/schedule.html

Приветствия

Ответ 8

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

Ответ 9

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

Ответ 10

Это зависит, но типичным является представление major.minor.release.build.

Где:

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

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

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

Ответ 11

Major.Minor.Bugs

(или некоторые изменения)

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

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

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

Ответ 12

Из файла С# 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.*")]

Ответ 13

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

Ответ 14

Обычно его:

MajorVersion.MinorVersion.Revision.Build

Ответ 15

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

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

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

Ответ 16

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

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

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

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

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

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

Ответ 17

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

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

Ответ 18

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

Релиз исправления ошибок должен поддерживать совместимость с двоичным кодом, источником и сериализацией.

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

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

Я написал больше об обосновании здесь.

Ответ 19

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

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

Ответ 20

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

Обычно первые два числа представляют собой майор и второстепенную версию, то есть 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" для моего управления версиями.

Ответ 21

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

Ответ 22

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

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

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

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

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

Ответ 23

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

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

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

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

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

Ответ 24

Заметки о процессе сборки программного обеспечения

Ответ 25

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

Ответ 26

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

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

Ответ 27

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

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

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

Ответ 28

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

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

Ответ 29

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

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

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

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

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

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