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

Question

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

Answer 1

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

Answer 2

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

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

Answer 3

Немного зависит от языка, например, 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» для управления версиями.

Answer 4

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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

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

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

Answer 9

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

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

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

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

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