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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Зависит немного от языка, Дельфи и C#, например, имеют различные значения.

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

третье число может относиться к "действительно незначительной" версии или пересмотру. 1.0.1 просто очень маленький bugfix к 1.0.0, например. Но это может также нести число Пересмотра от Вашей Системы управления исходным кодом или когда-либо увеличивающее число, которое увеличивает с каждой сборкой. Или Метка даты.

Немного больше детали здесь . "официально", в .net, эти 4 числа являются "Главными. Незначительный. Сборка. Пересмотр", тогда как в Дельфи там являются "Главными. Незначительный. Выпуск. Сборка". Я использую "Главный. Незначительный. ReallyMinor. SubversionRev" для моего управления версиями.

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

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

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

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

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

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

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

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

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

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

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

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

Все выбирают то, что они хотят сделать с этими числами. Я соблазнился к разъединениям вызова a.b.c, так как это довольно глупо так или иначе. Однако что я видел по последним 25 +, годы разработки имеют тенденцию прокладывать себе путь. Скажем, Ваш номер версии 1.2.3.

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

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

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

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

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

Главный. Незначительный. Ошибки

(Или некоторое изменение на том)

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

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

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

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

, Где:

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

Так, например, 1.9.0.1, средства, что это - версия 1.9 Вашего программного обеспечения, после 1,8 и 1.7, и т.д. где 1.7, 1.8 и 1.9 все в некотором роде обычно добавляют небольшие количества новых возможностей вместе с bugfixes. Так как это - x.x.0.x, это - первоначальная версия 1,9, и это - первая сборка той версии.

можно также найти хорошую информацию о статья Wikipedia о предмете .

Обычно:

MajorVersion. MinorVersion. Пересмотр. Сборка

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

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

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

Аплодисменты

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

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, Предназначенных Что-то. В наше время люди разочаровываются в номерах версий и идут с глупыми именами как "Энергичная фига" (или что-то как этот) и "hardy heron" и "europa" и "ganymede". Конечно, это намного менее полезно, потому что, Вы собираетесь выбежать из лун Юпитера, прежде чем Вы прекратите изменять программу, и так как нет никакого очевидного упорядочивания, Вы не можете сказать, который является более новым.

major.minor [.maintenance [.build]]

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

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

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

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

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

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