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

Question

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

Answer 1

В версии 1.9.0.1:

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

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

• : Bug выпуск исправление

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

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

Answer 2

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

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

Answer 3

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

Answer 4

MAJOR.MINOR [.maintenance [.build]]

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

Answer 5

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

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

Приветствия

Answer 6

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

Answer 7

Обычно его:

MajorVersion.MinorVersion.Revision.Build

Answer 8

Сочетание мажор, минор, патч, строить, исправления безопасности и т.д.

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

Answer 9

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

Answer 10

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

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

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

Answer 11

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

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

Answer 12

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

Где:

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

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

Вы также можете найти полезную информацию о Wikipedia article on the subject.

Answer 13

Major.Minor.Ошибки

(Или некоторые вариации на что)

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

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

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

Answer 14

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

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

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

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

Answer 15

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

Answer 16

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

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

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

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

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

Answer 17

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

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

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

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

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

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

Answer 18

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

// 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.*")] 

Answer 19

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

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

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

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

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

Answer 20

Notes on the Software Build Process

Answer 21

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

Answer 22

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

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

Answer 23

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

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

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

Answer 24

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

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

Answer 25

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

Answer 26

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

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

Answer 27

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

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

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

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

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

Answer 28

http://semver.org/

«Учитывая номер версии 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 формат."