Что на самом деле означают версии обновления?

18

Многие обновления программного обеспечения следуют схеме v0.1 до v0.2 до v2.6.5.6 . Что на самом деле означают эти «обновления» программного обеспечения? Всегда ли соблюдается отраслевой стандарт или программисты постоянно поднимают обновление # или добавляют больше десятичных дробей?

deployment software-updates software-distribution Джеймс Мертц
источник
12
@ S.Lott Поскольку я довольно новичок в программировании, я не знаю особенностей. Это лучший способ спросить, что я могу придумать.
Джеймс Мерц
9
@ S.Lott, откажись от кофеина, сэр, это делает тебя раздражительным.
ocodo
2
@ S.Lott не стесняйтесь редактировать по своему усмотрению, чтобы улучшить вопрос. Я чувствую, что вы знаете, что я ищу. Однако я чувствую, что предоставленные ответы были очень хорошими. Я также чувствую, судя по положительным голосам в моем предыдущем комментарии, что я сделал все, что мог, и что вопрос в порядке, как есть. Однако я приветствую критику, а также правки. Делай, как считаешь нужным. Для меня я оставляю это в покое.
Джеймс Мерц
1
@ S.Lott Вопрос, как мне кажется, довольно ясен. Я не думаю, что перечисление конкретной организации, пишущей стандарты, было бы значительным улучшением. Если вы чувствуете иначе, не стесняйтесь редактировать. У вас есть представитель для этого.
Адам Лир
3
@ С.Лотт: «Есть ли отраслевой стандарт» совершенно нормально. Да, есть отраслевые стандарты! Неважно, кто их пишет: KronoS хочет знать, что означают версии, он сам выбирает, насколько подробно он пойдет ... Возможно, вам следовало упомянуть, что вы считаете этот вопрос широким? Простое изучение деталей не дает пользователю ясного объяснения, подсказывает пользователю определение: слово не дает ясного объяснения пользователю, говорит, что это бессмысленно после того, как ваш первый комментарий не сделает это понятным для пользователя.
Тамара Вийсман

Ответы:

16

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

Сказав это, изобретатель Gravatars и соучредитель GitHub ( Том Престон-Вернер ) создал документ « Семантическое управление версиями », который более чем стоит прочитать.

Вот кроме вступления:

В качестве решения этой проблемы я предлагаю простой набор правил и требований, которые определяют, как номера версий присваиваются и увеличиваются. Чтобы эта система работала, сначала нужно объявить публичный API. Это может состоять из документации или выполняться самим кодом. Несмотря на это, важно, чтобы этот API был ясным и точным. После того, как вы определили свой публичный API, вы сообщаете об изменениях в нем с определенными приращениями к номеру вашей версии. Рассмотрим формат версии XYZ (Major.Minor.Patch). Исправления ошибок, не влияющие на API, увеличивают версию исправления, обратные совместимые добавления / изменения API увеличивают младшую версию, а обратно несовместимые изменения API увеличивают основную версию.

Я называю эту систему «Семантическим версионированием». В соответствии с этой схемой номера версий и то, как они изменяются, передают значение о базовом коде и о том, что было изменено из одной версии в другую.

Дэн МакГрат
источник
7

С 4 цифрами это обычно MajorV.MinorV.PatchNum.BuildNum, по крайней мере, где я работаю.

Я лично предпочитаю схему управления версиями Ubuntu - она ​​делает жизнь намного проще.

работа
источник
Какова их схема? Почему вы предпочитаете их?
Джеймс Мерц
3
Ubuntu 10.10 = октябрь 2010 г., Ubuntu 10.04 = апрель 2010 г., Ubuntu 11.04 = Aprial 2011, Ubuntu 9.10 = октябрь 2009 г. и т. Д. Это упомянуто в той ссылке на Википедию от Shaun.
Работа
2
Хорошая вещь об использовании дат в качестве номеров версий заключается в том, что - если не случится какой-то странный парадокс времени - ваш номер версии всегда будет в правильном порядке. Для большинства из нас легче вспомнить, что сегодня 2011.02.13, чем пытаться выяснить, какой должна быть версия нового выпуска.
jmort253
@ jmort245, точно! Искусственные системы довольно грязные. Чокнутые банки думают, что в году 360, 362, 365, 366 и т. Д. Система управления версиями - еще одно из этих глупых созданий. Временные метки не заставляют нас задуматься, хотя чтение и вычисление 20050207 занимает немного больше времени, чем 502. Какое программное обеспечение выпускается чаще, чем раз в месяц?
Работа
2
@job: Но использование версий позволяет привязывать функции к конкретным основным или второстепенным версиям. Поэтому, если у меня есть версия 2, я знаю, что у меня есть функция X, в то время как версия 1 не имеет версии X.
Мартин Йорк,
6

Короче говоря, нет стандарта, и компании делают все, что хотят. По сути, чем больше у вас чисел, тем меньше количество изменений, представленных каждым числом. Как правило, вы увидите, по крайней мере, версию xy, где xa означает изменение x для основных выпусков (значительное улучшение / развертывание функций), а y означает незначительные выпуски (значительные исправления или исправления дефектов). Большее количество десятичных дробей после этих двух может означать для компании разные вещи, хотя часто вращаются вокруг небольших сборок контента или исправлений, которые представляют собой более быстрые и мелкие исправления.

В Википедии есть статья, которая освещает это более подробно.

Shaun
источник
3

Целью номеров версий является предоставление справки для отчетов о проблемах. Единственное требование состоит в том, чтобы каждый выпуск имел уникальный номер версии. Некоторые числа приводятся в движение маркетингом - большие целые числа легче продать, а такие цифры как 10 (римская цифра X) действительно броские. Некоторые люди используют некоторые варианты семантического управления версиями:

MAJOR.MINOR.MICRO.BUILD

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

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

Некоторые группы добавляют дополнительную семантику, например, нечетные приращения MINOR предназначены для экспериментальных сборок, а чётные приращения MINOR предназначены для рабочих выпусков ( ядро Linux использует этот подход).

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

Берин Лорич
источник