wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Нумерация версий программного обеспечения: Software versioning / Хабр

alexxlab
No Comments

Содержание

Нумерация версий программного обеспечения

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

Вариант 1. Нумерация целым числом

Обычно программы нумеруются целыми числами 1,2,3,4,5,6,7 и т.д. когда новая версия программы сложна, долго пишется и появляется только раз в год или несколько лет. После того, как такая программа будет протестирована, она помечается целым номером и выпускается для использования. Какие-либо мелкие изменения, добавляемые в процессе обслуживания программы, не учитываются в нумерации. Например, целым числом нумеруется Corel Draw (Corel Draw 10, Corel Draw 11)

Вариант 2. Десятичная дробь

Другой способ, который позволяет указать в версии программы серьезные и не большие изменения — это нумерация десятичной дробью. Например, как правило первая версия программы получает номер 1.0. При небольшом изменении увеличивается вторая цифра — 1.1. А при добавлении новой функции, изменяется вновь первая цифра, а вторая, следующая за ней, обнуляется — 2.0.

Вариант 3. Последовательные числа

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

  • Первое число — старшая версия (major), изменяется при кардинальных изменениях программы

  • Второе число — младшая версия (minor), изменяется при значительных изменениях функциональности

  • Третье число (или буква) — стадия разработки
    • Альфа версия — стадия тестирования приложения, число 0 или символ a

    • Бета версия — стадия публичного тестирования приложения, число 1 или символ b

    • RC (Release candidate) — релиз-кандидат — стадия-кандидат на то, чтобы стать стабильной версией, число 2 или символы rc

    • RTM (Release To Manufacturing) — релиз — стабильная версия приложения, число 3 или символы rtm

    • GA (General availability) — общедоступный релиз

Он может отсутствовать, и тогда вместо него ставится следующее число.

  • Четвертое число — небольшие изменения (micro, maintenance), изменяется при любом, даже незначительной правке программы

Когда одно из чисел увеличивается, то все следующие за ним сбрасываются до нуля: 1.0.0, 1.0.1, 1.0.2, 1.1.0 и т.д. Часто, последний ноль может отбрасываться из версии, например: 1.0.0 = 1.0

Например, последовательные числа используют в Adobe Photoshop (Adobe Photoshop 7.0)

Вариант 4. Нумерация годом

Обычно, год используют в качестве нумерации для программных продуктов, которые долго разрабатываются и новые версии которых выходят не очень часто. Например, продукты того же Microsof, взять хотя бы их операционную систему или пакеты офисных утилит Word, Excel, PowerPoint и т.п.

Вариант 5. Нумерация текстом

Кроме чисел, в нумерации программы могут участвовать и различные буквы. Например, как это сделано в интегрированной среде разработки Delphi (Delphi XE)

Выбор, как именно нумеровать программу, выбирается по следующим причинам:

  • в зависимости от использования системы контроля версии или иных инструментов разработки

  • частота изменений в программе

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

Какой именно тип нумерации версий используете вы?

Автор

Программист с образованием в области IT и опытом разработки на разных языках. Автор статей по программированию. Общий опыт работы в сфере IT и интернета более 5 лет.

Какие способы нумерации версий существуют? — Хабр Q&A

Не скажу что гуру, но возможно и мой взгляд на версирование поможет чем-то.

Версирование ПО помогает:

1) Маркетингу

2) Саппорту

3) Разработчику

4) Тестировщику

п.1. Маркетолог может сказать «Ув. пользователь мы выпустили новую мажорную версию, в этой версии продукта много багфиксов и много вкусных фич.».

п.2. Специалист саппорта может иметь возможность отвечать более предметно на проблемы, к примеру «По лиц.политике одна мажорная версия действительна в течении… месяцев, Ваша версия устарела. Вам стоит связаться с отделом продаж для Обновления» или «Мы не можем воспроизвести Вашу ситуацию какая версия продукта у Вас стоит?»

п.3 Разработчик увидев задачу в баг-трекере может сказать «Я чего-то не пойму, для stable-ветки комиты есть, баг исправлен. В какой конкретно версии это воспроизводится?»

п.4. Тестировщик также как и разработчик может утверждать «Я протестировал фикс баги на новой версии…, а также версии… проблема не воспроизводится, баг пофикшен»

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

Из этого вытекают след. вопросы:

1) Какова судьба софта проданного покупателю?

2) Нужно ли хранить историю билдов и версий софта или достаточно иметь один stable-разлив?

3) Как Вы хотите сообщать тех.специалистам о том что Ваша программа изменилась координально и возможно она не совместима с форматами пред. версий или же она просто получила доп. баг-фиксы и несколько новых фич?

4) Хотите ли вы говорить покупателям что Вы реально круто поработали и им пора бы заплатить денег Вам чтобы Вашу работу оценить?

Как правило, видя изменение мажорной версии многие спецы задаются вопросами:

1) Совместима ли новая версия с прежними форматами?

2) Изменился ли GUI и нужно ли обновлять инструкции использования в корпоративной документации нашей компании?

3) Надо ли проводить приемочное испытание?

И ряд. др. важных вопросов

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

Нумерация версий программы |

У многих начинающих разработчиков возникает вопрос: как назначать версию своей программы?

Поделюсь своим опытом.

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

Приведу несколько примеров написания версии:

major.minor[.build[.revision]]

major.minor[.patch[.build]]

year.month.day[.build]

Разберем каждое значение.

Ревизия (Revision)

Номер ревизии (revision) в системе управления версиями (Version Control System, VCS или Revision Control System). Благодаря ему, можно легко получить исходный код конкретной версии, выгрузив его из хранилища. Как правило, данное значение начинается с 1 с последующим увеличением соответственно номеру ревизии и никогда не обнуляется. В силу того, что значение важно только для разработки, в нумерации программы его часто опускают.

Билд (build)

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

Патч или заплатка (patch)

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

Минорная версия (minor)

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

Мажорная версия (major) 

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

Для пред-релизных версий используют значение равное 0, получая номер вида 0.9.*.*

Год.Месяц.День (year.month.day)

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

Кроме указанных позиций, разработчики часто используют буквенные обозначения в номере версии:

alpha — как правило, первая публичная тестовая версия, перед выходом финальной версии. Служит для обкатки и тестирования.

beta — вторая публичная тестовая версия, перед выходом финальной версии. Также служит для тестирования.

RC, RC2 — релиз-кандидат (Relise Candidate) версия, почти готовая к релизу. Служит для окончательной проверки.

final — окончательная (финальная) версия программы. Используется крайне редко, обычно просто опускается.

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

В своей практике я использую написание вида major.minor[.patch[.build]], так как оно больше подходит к моему стилю разработки.

(Visited 2 398 times, 1 visits today)

Нумерация версий программного обеспечения | ИТ-Инженер (Краснодар)

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

Формат номера версии

Формат номера версии A.B.C.D[r], где:

  • A – главный номер версии (major version number).
  • B – вспомогательный номер версии (minor version number).
  • C – номер сборки, номер логической итерации по работе над функционалом версии A.B (build number).
  • D – Номер ревизии, сквозной номер назначаемый автоматически программным обеспечением хранения версий (SVN). Номер ревизии SVN должен синхронизироваться с номером ревизии в AssemblyInfo при каждой сборке релиза (revision number).
  • [r] – условное обозначение релиза.
A.B

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

C

Номер сборки (билда) (С) должен увеличиваться (зачастую) руководителем проекта по разработке всякий раз, когда продукт передаётся на тестирование.

D

Номер ревизии (D) увеличивается системой контроля версий (SVN) автоматически при работе с ней. Задача руководите проекта по разработке синхронизировать номер ревизии, генерируемый SVN, с номером указанным в AssemblyInfo в модулях проекта. Выполнять эту операцию нужно одновременно с увеличением номера билда (С).

[r]

Обозначение релиза соответствует этапу работы над проектом в рамках жизненного разработки. Выделяют следующие релизы:
• Pre-alpha (pa) – соответствует этапу начала работ над версией. Характеризуется большими изменениями в функционале и большим количеством ошибок. Pre-alpha релизы не покидают отдела разработки ПО.
• Alpha(a) – соответствует этапу завершения разработки нового функционала. Начиная с alpha версии новый функционал не разрабатывается, а все заявки на новый функционал уходят в план работ по следующей версии. Этап характеризуется высокой активностью по тестированию внутри подразделения разработки ПО и устранению ошибок.
• Beta (b) – соответствует этапу публичного тестирования. Это первый релиз, который выходит за пределы отдела разработки ПО. На этом этапе принимаются замечания от пользователей по интерфейсу продукта и прочим найденным пользователями ошибкам и неточностям.
• Release Candidate (rc) – весь функционал реализован и полностью оттестирован, все найденные на предыдущих этапах ошибки исправлены. На этом этапе могут вноситься изменения в документацию и конфигурации продукта.
• Release to manufacturing или Release to marketing (rtm) – служит для индикации того, что ПО соответствует всем требованиям качества, и готово для массового распространения. RTM не определяет способа доставки релиза (сеть или носитель) и служит лишь для индикации того, что качество достаточно для массового распространения.
• General availability (ga) – финальный релиз, соответствующий завершению всех работ по коммерциализации продукта, продукт полностью готов к продажам через веб или на физических носителях.
• End of life (eol) – работы по развитию и поддержке продукта завершены.
В скобках указаны сокращения, используемые для формирования номера релиза. Если в номере не указано ни одного сокращения, то считается что это релиз General availability (ga).
Помимо сокращённого обозначения в наименовании версии обозначение релиза должно указываться в исходных файлах проекта через атрибут:

1

[AssemblyConfiguration]

В случае большого количества проектов в решении рекомендуется использовать один файл GlobalAssemblyInfo.cs (или GlobalAssemblyInfo.vb) с указанием ссылки на него во всех проектах решения и именно в нём проставлять вид релиза.
Пример С#:

1
2

using System.Reflection;
[assembly: AssemblyConfiguration("Beta")]

Пример VB.NET:

1

Imports System.Reflection
Примеры

HBR 2.3.1.1260b – релиз HBR версии 2.3, сборка 1, ревизия 1260, бета.
HBR 2.3.2.1370rc – релиз HBR версии 2.3, сборка 2, ревизия 1370, релиз-кандидат.
HBR 2.3.5.1432 – релиз HBR версии 2.3, сборка 5, ревизия 1432, финальный релиз.

Версии модулей/дополнение

Если в составе ПО выделены модули или дополнения, то можно применять два подхода к ведению номеров их версий.
1. Синхронная нумерация – нумерация модулей и дополнений совпадает с версией самого приложения.
2. Индивидуальная нумерация – нумерация версии модуля или дополнения ведётся индивидуально как для отдельного самостоятельного приложения.
Первый подход рекомендуется применять на этапе активной разработки приложения до выхода первого ga-релиза в текущей версии. Если функционал модуля устоялся и не требует изменений при развитии других модулей или самого приложения, то рекомендуется применять второй подход.

Имя файла дистрибутива

Имя дистрибутива должно однозначно указывать продукт и полный номер версии.
При сборке дистрибутива как набора несжатых файлов корневая папка, в которой располагаются подпапки и несжатые файлы дистрибутива именуется по формату «<Имя продукта> A_B_C_D[r]».
При сборке дистрибутива как msi-файла, msi-файл должен переименовываться в «<Имя продукта> A_B_C_D[r]».
При сжатии в архив каталога с файлами дистрибутива архив должен именоваться аналогично: «<Имя продукта> A_B_C_D[r]».
Такой принцип нумерации версий использует большинство разработчиков десктопных приложений.

Содержимое статьи чуть менее, чем полностью взято у автора https://habrahabr.ru/users/ifmalex/

Вы также можете ознакомиться с другими статьями:

Wikizero — Нумерация версий программного обеспечения

Наиболее распространённый в настоящее время способ нумерации версий

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

Версия программы может быть целым числом (Corel Draw 11), последовательностью чисел (JDK 1.0.3), годом (Windows 2000) или текстом (Embarcadero Delphi XE). В любом случае, система версионирования выбирается по нескольким критериям:

  • Поддержка той или иной системы со стороны ПО для разработки (компилятора, системы контроля версий и т. д.).
  • Частота выхода новых версий и их «сырость». Сложная программа, выпускаемая раз в несколько лет и перед выпуском проходящая всеобъемлющее тестирование, может именоваться как «Microsoft Word 97 SP2», в то время как в программе с частыми малостабильными выпусками приходится вводить более сложную нумерацию.
  • Степень совместимости сетевых протоколов, документов или надстроек сторонних разработчиков — например, «старшая» версия увеличивается с каждым изменением ABI или API.
  • Маркетинговые соображения.

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

Последовательные номера[править | править код]

Изначально программы нумеровались числами 1, 2, 3 и т. д. — аналогично изданиям книг. Также последовательные номера могут быть основаны на каком-то техническом счётчике (например, номер версии в системе управления версиями).

Ныне последовательными номерами обозначают редко выпускаемые программы, которые выходят уже стабильными. Например, Corel Draw 11, Windows 10. У таких программ мелкие сервисные изменения обычно «заметаются под ковёр», не изменяя видимой версии (меняя лишь техническую, доступную, например, из меню «О программе»). Крупные изменения с новой функциональностью, но не тянущие на новый продукт, как правило, обозначают десятичной дробью (Windows 8.1).

Десятичная дробь[править | править код]

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

Номер версии является десятичной дробью в американском формате (через точку). Например, первая версия получает номер 1.0, следующая за ней — 1.1, с небольшим изменением — 1.11, создаётся новый продукт с новой функциональностью — 2.0. Чем сильнее увеличивается дробь, тем более значимо изменение. Разработчики порой перескакивают, например, от версии 2.0 сразу к 2.5, чтобы обозначить добавление нескольких значимых функций в программу, но их недостаточно, чтобы изменить главный номер версии (Turbo Pascal 5.0 → 5.5).

Для предварительных, неофициальных версий применяют числа меньше 1: скажем, 0.1 или 0.9.

Сравнение версий идёт по правилам десятичных дробей: 0.9 < 1.0 < 1.01 < 1.1 = 1.10 < 1.11 < 1.2 = 1.20 < 2.0 < 2.5.

Последовательность чисел[править | править код]

Этот способ принят, например, в Windows API. Версия состоит из нескольких чисел (как правило, трёх), разделённых точкой: например, 1.5.2. Первое из них — старшая версия (major), второе — младшая (minor), третья — мелкие изменения (maintenance, micro).

При увеличении одного из чисел все идущие после него сбрасываются до нуля: 1.0.0, 1.0.1, 1.0.2, 1.1.0, 1.2.0, 1.2.1, 2.0.0… Последний ноль может опускаться: 1.0.0 = 1.0.

Библиотеки Unix используют схему версионирования current.revision.age. Current — текущий номер API, revision — счётчик версий в пределах одного API, age — разница между последней и первой версиями поддерживаемого API[1].

Для определения старшинства версий сравнивают сначала старшие версии, потом младшие, потом микро- как целые числа: 1.1.0 = 1.1 < 1.1.2 < 1.10.0 = 1.10 < 1.11.0 < 1.20.0 < 1.100.0 < 1.100.1 < 2.0.0.

Иногда четвёртым числом идёт номер сборки со сквозной нумерацией. Эта цифра может увеличиваться на единицу с каждым выпуском (1.0.0.1 < 1.0.1.2 < 1.0.2.3 < 1.1.0.4), либо браться из какого-нибудь технического счётчика (компиляций, ночных сборок, версий кода в системе контроля версий — например, 1.5.2.7682). В Microsoft Office четвёртым числом закодирована дата выпуска[2].

Опять-таки, 1.0 считается первой официальной версией; 0.1 или 0.9 — предварительными выпусками.

Буква в качестве младшей версии[править | править код]

Иногда вместо третьего числа применяется буква. Так, когда в DotA 6.42 нашли ошибку, новой версии дали название 6.42b. Это значит: игра остаётся той же, с тем же расположением препятствий и тем же балансом, но с исправленной ошибкой. Дальнейшие исправления ошибок именуются 6.42c, 6.42d и т. д.

Указание стадии разработки[править | править код]

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

Например, 2.0 alpha1 < 2.0 alpha2 < 2.0 beta < 2.0 rc1 < 2.0 < 2.0 sr1.

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

  • 0 — альфа
  • 1 — бета
  • 2 — выпуск-кандидат
  • 3 — публичный выпуск

Например:

  • 1.2.0.1 вместо 1.2-a
  • 1.2.1.2 вместо 1.2-b2 (бета с несколькими исправленными ошибками)
  • 1.2.2.3 вместо 1.2-rc3 (выпуск-кандидат)
  • 1.2.3.0 вместо 1.2-r (для коммерческого распространения)
  • 1.2.3.5 вместо 1.2-r5 (для коммерческого распространения со многими исправленными ошибками)

Внутри компании также может указываться стадия разработки (например, 1.2.3 < 1.2.3r9 < 1.2.4), в то время как в официальных выпусках такого нет — например, чтобы исключить путаницу среди тестеров или выдать клиенту какую-то версию — возможно, нестабильную, но исправляющую его ошибку.

Между сериями 1.0 и 2.6.x ядро Linux использовало нечётные номера для бета-версий, и чётные — для стабильных. Например, Linux 2.3 был серией в разработке, а Linux 2.4 — серией стабильных выпусков, в которую перерос Linux 2.3. В номере выпуска Linux kernel сначала писался номер второстепенной версии, а затем номер выпуска в возрастающем порядке. Например Linux 2.4.0 → Linux 2.4.22. После выпуска 2.6 в 2004 году Linux больше не использует эту систему, теперь цикл выпуска намного короче. Сейчас они просто увеличивают третье число, используя при необходимости четвёртое.

Такая же система «чёт-нечет» используется некоторыми другими продуктами с длинным циклом разработки, такими как GNOME.

Алфавитно-цифровое название[править | править код]

Чаще всего применяется ПО с долгой историей и редко выходящими версиями (Windows Vista).

Если счётчик версий зашёл слишком далеко и надо его сбросить, также используются алфавитные коды: Adobe Photoshop 7.0 < CS < CS2 < … < CS6 < CC < CC 2014.

Иногда в дополнение к обычной версии используется алфавитно-цифровое подназвание: Ubuntu 9.04 Jaunty Jackalope, Embarcadero Delphi 10.2 Tokyo.

Дата[править | править код]

Год выпуска применяется чаще всего в ПО с редко выходящими версиями, например: Windows Server 2003, Microsoft Office 2014.

Разработчики проекта Wine также сначала использовали даты при нумерации версий, они указывали год, месяц и день выпуска: «Wine 20040505». Сейчас Wine использует «стандартную» нумерацию выпусков, последняя версия 2010 года имеет номер 1.2. Компания Ubuntu Linux использует похожую схему нумерации, например, выпуск октября 2010 года пронумерован как Ubuntu 10.10. Аналогичная схема на текущий период используется компанией Microsoft для нумерации обновлений Windows 10, хотя у них номер версии обычно на 1 меньше номера месяца, например, Fall Creators Update (1709) вышел 17 октября 2017 года, а April 2018 Update (1803) несмотря на номер «03» в названии вышло в апреле 2018.

При использовании дат в нумерации версий следует использовать схему ISO «год-месяц-день» (это упрощает сравнение версий на старшинство), причём дефис можно опускать.

Внутренние версии[править | править код]

Часто программа имеет как торговое название, так и внутреннюю версию, составленную по всем правилам. Например, Java SE 5.0 имеет внутреннюю версию 1.5.0, Windows 7 — версию 6.1[3]. Различные сборки файлов Windows могут называться, например, 6.1.7600.16385.

Подобные технические версии сравнивают с солдатским жетоном[2]. Как и на поле боя, они нужны в экстренных случаях — когда программа работает не так и нужно связаться с разработчиком.

Экзотические схемы[править | править код]

Дональд Кнут нумерует версии системы компьютерной вёрстки ΤΕΧ последовательными приближениями числа π{\displaystyle \pi }: 3.0 < 3.1 < 3.14 и т. д. Номер последнего стабильного выпуска — 3.141592653. Версии другого детища Дональда Кнута языка METAFONT нумеруются приближениями к числу e. Версия за март 2008 года имела номер 2.718281.

SuSE Linux начал счёт версий с 4.2, как отсылка на известную книгу Дугласа Адамса.

Версия 1.0 как ключевой этап разработки[править | править код]

Коммерческие программы, как правило, начинают нумеровать свои версии с 1.0. Считается даже, что версия 1.0 исключительно сыра и поэтому нужно как можно быстрее дойти до 1.2 или даже до 2.0.

В бесплатных и свободных программах 1.0 считается моментом, когда программа признана готовой к широкому применению неспециалистами. При этом первоначальные версии программы нумеруются как 0.1, 0.2 и т. д. FreeDOS пришёл к версии 1.0 в 2006 году — когда DOS уже практически нигде не использовался. Эмулятор игровых автоматов MAME никогда не дойдёт до версии 1.0, поскольку история игровых автоматов продолжается и поныне.

Маркетинг и суеверия[править | править код]

Коммерческому ПО, чтобы название лучше смотрелось, приходится подключать маркетологов. Например, в странах Азии распространена тетрафобия, поэтому в номерах версий избегают цифры 4. В Европе число 13 считается несчастливым, его или пропускают, или заменяют на X3.

Если история программы очень длинна, её иногда приходится сбрасывать: Adobe Photoshop 7.0 < 8.0 < CS < CS2.

Одной из причин того, что не было Winamp 4, стал каламбур: Winamp 4 skin и англ. foreskin — «крайняя плоть»[4].

Пропуски в версиях[править | править код]

Иногда разработчик пропускает номер версии, чтобы не отставать от конкурентов или других продуктов той же компании: например, Microsoft Access перепрыгнул сразу от 2.0 к 7.0. Netscape Communicator пропустил пятую версию, так как Internet Explorer добрался уже до 6.0; к тому же версию 5.0 в User-Agent’ах застолбили тестовые выпуски браузера Mozilla Suite.

В Sun Solaris отбросили первую цифру: 2.8 и 2.9 в маркетинговых материалах именовались 8 и 9; Java SE 1.5.0 и 1.6.0 — как Java 5 и 6. Slackware Linux в 1999 году прыгнул от версии 4 сразу к 7.

Microsoft Windows 10 выходит после 8.1.

PHP перескакивает от 5 к 7, причиной объявлено то, что версия 6 оказалась распиаренной, но нереализуемой, и многие из её нововведений были присоединены к 5-й ветке[5].

Алгоритмы определения старшинства версий[править | править код]

Часто нужно программно определять, какая из двух версий старше — например, «пузыри» поддерживаются в Windows начиная с 2000[6], а в более ранних версиях надо поступать другими способами. Такая проверка делается по довольно сложным правилам: например, если версия — десятичная дробь, сначала требуется сравнить целые части как числа; если они равны, то дробные — как строки. Если версия — тройка или четвёрка чисел, то сравнивают числа по одному, пока не будет зафиксировано неравенство.

Поскольку чрезмерно сложные алгоритмы чреваты ошибками[7], а модульные тесты писать не всегда есть время, часто обходятся упрощёнными вариантами: например, строят с помощью

Нумерация версий программного обеспечения — Карта знаний

  • Жизненный цикл успешной компьютерной программы может быть очень долгим; изменения в программе бывают разными — от исправления ошибки до полного переписывания. В большинстве случаев название программы остаётся тем же, изменяется подназвание — так называемая версия.

    Версия программы может быть целым числом (Corel Draw 11), последовательностью чисел (JDK 1.0.3), годом (Windows 2000) или текстом (Embarcadero Delphi XE). В любом случае, система версионирования выбирается по нескольким критериям:

    * Поддержка той или иной системы со стороны ПО для разработки (компилятора, системы контроля версий и т. д.)

    * Частота выхода новых версий и их «сырость». Сложная программа, выпускаемая раз в несколько лет и перед выпуском проходящая всеобъемлющее тестирование, может именоваться как «Microsoft Word 97 SP2», в то время как в программе с частыми малостабильными выпусками приходится вводить более сложную нумерацию.

    * Степень совместимости сетевых протоколов, документов или надстроек сторонних разработчиков — например, «старшая» версия увеличивается с каждым изменением ABI или API.

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

Источник: Википедия

Связанные понятия

Бе́йсик (BASIC, сокращение от англ. Beginner’s All-purpose Symbolic Instruction Code — универсальный код символических инструкций для начинающих) — семейство высокоуровневых языков программирования.

Фокал (Focal, акроним от англ. formula calculator) — интерпретируемый язык программирования высокого уровня, переработка языка JOSS.

Galaksija (Галаксия) — самодельный 8-разрядный домашний компьютер, разработанный журналистом и изобретателем Во́йя А́нтонич (Voja Antonić, Сербия). Компьютер был описан в специальном выпуске «Компьютеры в вашем доме» («Računari u vašoj kući») популярного научного журнала Galaksija, опубликованном в декабре 1983 года в Белграде. Компьютер распространялся в форме комплекта «сделай сам», но его можно было собрать и полностью самостоятельно. Позже компьютер предлагался и в полностью собранном виде.

«Ло́ренц» (нем. Lorenz-Chiffre, Schlüsselzusatz; Lorenz SZ 40 и SZ 42) — немецкая шифровальная машина, использовавшаяся во время Второй мировой войны для передачи информации по телетайпу. Была разработана компанией C. Lorenz AG в Берлине. Принцип работы машины был основан на поточном шифре Вернама.

Система управления версиями (от англ. Version Control System, VCS или Revision Control System) — программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.

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

Образ ПЗУ (ROM-image либо просто ROM) — двоичный файл, содержащий копию данных из микросхемы ПЗУ, обычно — из картриджа игровой приставки, из «прошивки» компьютера или сведения о конфигурации материнской платы аркадного автомата. Термин часто используется в контексте эмуляции: старые игры или программы, записанные в ПЗУ старого компьютера, копируются в файл образа ПЗУ и при помощи программы-эмулятора могут быть запущены на современном компьютере.

Это статья об азартной игре. См. также Пасьянс Маджонг.Маджонг или мацзян (кит. трад. 麻將, упр. 麻将, пиньинь: májiàng, палл.: мацзян) — китайская азартная игра с использованием игральных костей для четырёх игроков (каждый играет за себя). Широко распространена в Китае, Японии и других странах Восточной и Юго-Восточной Азии. Игра ведётся костями, напоминающими костяшки домино, по правилам подобна покеру, требует от играющих таких качеств, как опыт, память и наблюдательность. В игре присутствует также…

Подробнее: Маджонг

«Специалист» — любительский 8-разрядный микрокомпьютер. Разработан в 1985 году Анатолием Фёдоровичем Волковым, г. Днепродзержинск Днепропетровской области (изначально компьютер назывался «Фахівець-85»). Схема и описание компьютера были опубликованы в журнале «Моделист-конструктор» в 1987 году.

Язык программирования Си разрабатывался в период с 1969 по 1973 годы в лабораториях Bell Labs. Согласно Ритчи, самый активный период творчества пришёлся на 1972 год. Язык назвали «Си» (C — третья буква английского алфавита), потому что многие его особенности берут начало от старого языка «Би» (B — вторая буква английского алфавита). Существует несколько различных версий происхождения названия языка Би. Кен Томпсон указывает на язык программирования BCPL, однако существует ещё и язык Bon, также созданный…

Подробнее: История языка Си

Бейсик Вильнюс (также известен как BASIC-86) — реализация языка программирования Бейсик для 16-разрядных домашних и учебных компьютеров с процессорами архитектуры PDP-11. Первоначально разработан в вычислительном центре Вильнюсского государственного университета (ВЦКП ВГУ) в 1985 году.

Визуа́льно неоднозна́чные си́мволы (англ. Visually Confusable Characters, или VCC) — термин, используемый для обозначения проблемы компьютерной безопасности, когда две различные строки символов выглядят на экране монитора очень похоже.

Прогресс компьютерных технологий определил процесс появления новых разнообразных знаковых систем для записи алгоритмов языков программирования. Смысл появления такого языка — упрощение программного кода.

Подробнее: История языков программирования

А́да (Ada) — язык программирования, созданный в 1979—1980 годах в ходе проекта Министерством обороны США с целью разработать единый язык программирования для встроенных систем (то есть систем управления автоматизированными комплексами, функционирующими в реальном времени). Имелись в виду прежде всего бортовые системы управления военными объектами (кораблями, самолётами, танками, ракетами, снарядами и т. п.). Перед разработчиками не стояло задачи создать универсальный язык, поэтому решения, принятые…

Сравнение с обменом (англ. compare and set, compare and swap, CAS) — атомарная инструкция, сравнивающая значение в памяти с одним из аргументов, и в случае успеха записывающая второй аргумент в память. Поддерживается в семействах процессоров x86, Itanium, Sparc и других.

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

Заимствование шифротекста (англ. ciphertext stealing, CTS) в криптографии — общий метод использования блочного режима шифрования, позволяющий обрабатывать сообщения произвольной длины за счет незначительного увеличения сложности реализации. В отличии от дополнения, получившийся шифротекст не становится кратным размеру блока используемого шифра, а остается равным длине исходного открытого текста.

О́чередь — абстрактный тип данных с дисциплиной доступа к элементам «первый пришёл — первый вышел» (FIFO, англ. first in, first out). Добавление элемента (принято обозначать словом enqueue — поставить в очередь) возможно лишь в конец очереди, выборка — только из начала очереди (что принято называть словом dequeue — убрать из очереди), при этом выбранный элемент из очереди удаляется.

Алгоритм пекарни Лампорта алгоритм разделения общих ресурсов между несколькими потоками путём взаимного исключения. Опубликован учёным в области информатики Лесли Лампортом в 1974 году.

Экстрема́льное программи́рование (англ. Extreme Programming, XP) — одна из гибких методологий разработки программного обеспечения. Авторы методологии — Кент Бек, Уорд Каннингем, Мартин Фаулер и другие.

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

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

Класс — это элемент ПО, описывающий абстрактный тип данных и его частичную или полную реализацию. Другие абстрактные типы данных — метаклассы, интерфейсы, структуры, перечисления, — характеризуются какими-то своими, другими особенностями. Наряду с понятием «объекта» класс является ключевым понятием в ООП (хотя существуют и бесклассовые объектно-ориентированные языки, например, Self, Lua; подробнее смотрите Прототипное программирование). Суть отличия классов от других абстрактных типов данных состоит…

Спарклайн (англ. sparkline, от англ. spark — искра, англ. line — линия) — термин, который придумал Эдвард Тафти для обозначения небольших по размеру, но достаточно информационно-плотных графиков.

Тре́нер, тре́йнер (англ. trainer) — программа, предназначенная для изменения игровых параметров (например, «очков жизни», чтобы сделать игрока «бессмертным»), обычно они работают непосредственно с оперативной памятью компьютера. Наиболее полезен для игр, в которых не предусмотрены чит-коды.

Эпоха 16-битных приставок является четвёртым поколением игровых систем, началась 30 октября 1987 года с японского релиза NEC PC Engine (известного как TurboGrafx-16 на рынке Северной Америки). Несколько других компаний стали обращать внимание на созревание видео-игровой индустрии и начали строить планы на выпуск приставки в будущем. Тем не менее, большинство приставок, за исключением Neo Geo от SNK, не были широко распространены. Главными конкурентами в этом поколении были Sega Mega Drive и Super…

Подробнее: Четвёртое поколение игровых систем

В истории компьютерных игр, эпоха 32/64-разрядных игровых систем стала пятым поколением игровых приставок. В это время на рынке доминировали три системы — Sega Saturn (1994), Sony PlayStation (1994) и Nintendo 64 (1996). Эта эпоха началась в 1993 году и закончилась в 2006. Демография продаж этих консолей сильно различалась, но все три приставки участвовали в консольной войне этой эры. FM Towns Marty, 3DO, PC-FX и Atari Jaguar тоже были частью пятого поколения, но их продажи были относительно невелики…

Подробнее: Пятое поколение игровых систем

Криптологическая бомба (польск. Bomba kryptologiczna) — аппарат, предложенный польским криптологом Марианом Реевским и разработанный в 1938 году совместно с двумя его коллегами-математиками Ежим Рожицким и Генрихом Зыгальским для систематической расшифровки сообщений, зашифрованных немцами при помощи Энигмы. Предпосылкой к созданию машины стала ненадёжная процедура удвоения ключа, использовавшаяся немцами, позволившая определить дневные настройки Энигмы.

Цикло́метр — устройство, разработанное, вероятнее всего, в период с 1934 года по 1935 год польским криптологом Марианом Реевским — сотрудником польского Бюро шифров секции BS-4, которая занималась криптоанализом немецких систем шифрования. Данное устройство позволяло значительно облегчить расшифровку текста, зашифрованного немецкой портативной шифровальной машиной «Энигмой».

Генератор ключей (жарг. кейген, киген) (от англ. keygen (произносится как «ки́джен»), key generator) — небольшая программа, которая генерирует…

В первое поколение игровых систем выделяют игровые системы, произведённые с 1972 по 1977 годы, начиная с Magnavox Odyssey. Поколение продлилось до 1977 года, когда изготовители приставок типа «Pong» покинули рынок из-за обвала видеоигровой индустрии в 1977 году, и дальнейшего успеха приставок, основанных на микропроцессорах. В Японии поколение продолжилось до 1980 года, когда было прекращено производство Nintendo Color TV Game.

Систе́ма прове́рки правописа́ния (также спелл-че́кер от англ. spell checker) — компьютерная программа, осуществляющая проверку заданного текста на наличие в нём орфографических ошибок. Найденные ошибки или опечатки отмечаются специальным образом — обычно для этого используется подчёркивание. В некоторых случаях пользователю помимо указания на места возможных ошибок предоставляется возможность выбрать один из правильных вариантов написания. Может быть также выведен комментарий, объясняющий, каким…

Форт (англ. Forth) — один из первых конкатенативных языков программирования, в котором программы записываются последовательностью лексем («слов» в терминологии языка Форт). Математические выражения представляются постфиксной записью при использовании стековой нотации. Поддерживает механизмы метарасширения семантики и синтаксиса языка для адаптации к нужной предметной области. Синтаксис базового уровня в Форте прост и состоит из единственного правила: «все определения разделяются пробелами». Определения…

Бытовой (домашний) компьютер — компьютер, предназначенный для применения в быту. Термином бытовой или домашний компьютер обозначаются относившиеся к дешёвому сегменту представители второго поколения микрокомпьютеров, появившиеся на рынке в 1977 году и получившие широкое распространение в 1980-е годы. В отличие от более дорогих и мощных машин, обычно называвшихся профессиональными или, позднее, персональными компьютерами (калька с англоязычного термина Personal Computer), домашние компьютеры отличались…

Бэкпо́рт (от англ. back-porting) — применение (с возможной доработкой) патчей, предназначенных для основной, развивающейся в данный момент версии программы, к более старым версиям. Бэкпортирование осуществляется для поддержания «стабильных» версий (обычно производится разработчиком программы), или из актуальной — в устаревшие, не поддерживаемые (обычно производится сторонними энтузиастами). Самая распространённая причина бэкпортирования — решение проблем безопасности.

Вычислительная техника является важнейшим компонентом процесса вычислений и обработки данных. Первыми приспособлениями для вычислений были, вероятно, всем известные счётные палочки, которые и сегодня используются в начальных классах многих школ для обучения счёту. Развиваясь, эти приспособления становились более сложными, например, такими как финикийские глиняные фигурки, также предназначаемые для наглядного представления количества считаемых предметов. Такими приспособлениями, похоже, пользовались…

Подробнее: История вычислительной техники

Лисп (LISP, от англ. LISt Processing language — «язык обработки списков»; современное написание: Lisp) — семейство языков программирования, программы и данные в которых представляются системами линейных списков символов. Лисп был создан Джоном Маккарти для работ по искусственному интеллекту и до сих пор остаётся одним из основных инструментальных средств в данной области. Применяется он и как средство обычного промышленного программирования, от встроенных скриптов до веб-приложений массового использования…

Автома́тное программи́рование — это парадигма программирования, при использовании которой программа или её фрагмент осмысливается как модель какого-либо формального автомата. Известна также и другая «парадигма автоматного программирования, состоящая в представлении сущностей со сложным поведением в виде автоматизированных объектов управления, каждый из которых представляет собой объект управления и автомат». При этом о программе, как в автоматическом управлении, предлагается думать как о системе…

Североамериканский план нумерации (англ. North American Numbering Plan, NANP) — совместный телефонный план нумерации 24 стран и территорий: США (включая островные территории), Канады, Бермуд и 16 карибских государств. Имеет международный телефонный код 1.

Шахматный движок (англ. Chess engine) — компьютерная программа, предназначенная для просчитывания вариантов шахматных ходов.

Спор Таненба́ума — То́рвальдса состоялся между Эндрю Таненбаумом и Линусом Торвальдсом. Предметом спора было ядро Linux и архитектура ядер операционных систем в целом. Таненбаум начал спор в 1992 году в ньюсгруппе comp.os.minix сети Usenet, заявив, что микроядра вытесняют монолитные ядра, и поэтому Linux устарел уже в 1992 году. К спору присоединились другие известные хакеры, например, Дэвид Миллер и Теодор Цё.

Ло́го (англ. Logo) — язык программирования высокого уровня, разработанный в 1967 году Уолли Фёрзегом, Сеймуром Пейпертом и Синтией Соломон в образовательных целях для обучения детей дошкольного и младшего школьного возраста основным концепциям программирования (рекурсии, расширяемости и пр.).

Лексико́н — частично-компьютерная ролевая игра, придуманная Нилом Кришнасвами и популярная в среде поклонников инди-ролевых игр. По задумке автора, игра проходит в интернете на базе вики-движка. На создание игры его вдохновило произведение Милорада Павича «Хазарский словарь». Игроки берут на себя роль учёных (в общем для средневековья смысле этого слова), которые объединяются в попытке создания подобия энциклопедии или сборника трудов по истории и окружению какого-то определённого придуманного события…

Дополнение (англ. padding) в криптографии — добавление ничего не значащих данных к зашифровываемой информации, нацеленное на повышение криптостойкости. Различные техники дополнения применялись в классической криптографии , обширное применение техники дополнений нашли в компьютерных системах шифрования.

Сокеты Беркли — интерфейс программирования приложений (API), представляющий собой библиотеку для разработки приложений на языке C с поддержкой межпроцессного взаимодействия (IPC), часто применяемый в компьютерных сетях.

«Консольные войны» — термин, используемый для обозначения периодов интенсивной конкуренции за долю рынка между производителями игровых приставок (игровых консолей). Победителей в этих «войнах» можно определять по-разному: по степени проникновения и финансовым результатам, либо по привязанности и количеству любителей консоли и её игр. Сам по себе термин не предполагает «чистой» победы: в консольных войнах не решается, останется ли производитель на рынке или покинет его.

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

ⓘ Энциклопедия — Нумерация версий программного обеспечения

                                     

3. Алгоритмы определения старшинства версий

Часто нужно программно определять, какая из двух версий старше — например, «пузыри» поддерживаются в Windows начиная с 2000, а в более ранних версиях надо поступать другими способами. Такая проверка делается по довольно сложным правилам: например, если версия — десятичная дробь, сначала требуется сравнить целые части как числа; если они равны, то дробные — как строки. Если версия — тройка или четвёрка чисел, то сравнивают числа по одному, пока не будет зафиксировано неравенство.

Поскольку чрезмерно сложные алгоритмы чреваты ошибками, а модульные тесты писать не всегда есть время, часто обходятся упрощёнными вариантами: например, строят с помощью битовых полей длинное число 1.2.3.4 → 01020304 16; либо сравнивают версии как строки в лексикографическом порядке. Первое не сработает, если одно из чисел перейдёт за 256 1.0.257 < 1.1.0, но 010101 16 > 010100 16, второе — если выйдет версия 10 9.5 < 10.0, но «9.5» > «10.0».

Иногда подобные упрощения играют злую шутку: в первые годы популярности Windows выяснилось, что множество программ некорректно проверяли версию ОС, отказываясь работать под 4.0. Поэтому Windows 95 и Windows 98 имели внутренние версии 3.95 и 3.98.

Похожие ухищрения применялись в User-Agent’е браузера Opera при переходе с версии 9.64 на 10.00. Это вызвано тем, что некоторые сайты, реагирующие на User-Agent, либо сравнивали номера как строки 10.0 < 9.5, либо брали первую цифру 10.0 = 1.0. Разработчикам пришлось использовать запись Opera/9.80 вместо Opera/10.00, а настоящий номер версии добавить в конце UserAgent’а. Планировалось, что к 11-й версии UserAgent примет привычный вид, однако это ухищрение использовалось вплоть до перехода на движок Blink начало 2013 — при том, что переход на 10-ю версию произошёл ещё в 2009 году.

В PHP имеется специальная функция version_compare для определения старшинства версий.

Семантическое управление версиями 2.0.0 | Семантическое управление версиями

Сводка

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

  1. ОСНОВНАЯ версия при внесении несовместимых изменений API,
  2. MINOR версия, когда вы добавляете функциональность в обратно совместимую
    манера, и
  3. PATCH, когда вы исправляете обратно совместимые ошибки.

Дополнительные метки для метаданных предварительной версии и сборки доступны как расширения
к МАЙОРУ.MINOR.PATCH формат.

Введение

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

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

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

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

Спецификация семантического управления версиями (SemVer)

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ОБЯЗАТЕЛЬНО», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН»,
«НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом документе должны быть
интерпретируется, как описано в RFC 2119.

  1. Программное обеспечение

    , использующее семантическое управление версиями, ДОЛЖНО объявить общедоступный API.Этот API
    могут быть объявлены в самом коде или существовать строго в документации.
    Как бы то ни было, он ДОЛЖЕН быть точным и исчерпывающим.

  2. Нормальный номер версии ДОЛЖЕН принимать форму X.Y.Z, где X, Y и Z
    неотрицательные целые числа и НЕ ДОЛЖНЫ содержать начальные нули. X — это
    основная версия, Y — дополнительная версия, а Z — версия исправления.
    Каждый элемент ДОЛЖЕН увеличиваться численно. Например: 1.9.0 -> 1.10.0 -> 1.11.0.

  3. После выпуска версионного пакета содержимое этой версии
    НЕ ДОЛЖНЫ быть изменены.Любые модификации ДОЛЖНЫ быть выпущены как новая версия.

  4. Основная нулевая версия (0.y.z) предназначена для начальной разработки. Все может измениться
    в любое время. Публичный API НЕ СЛЕДУЕТ считать стабильным.

  5. Версия 1.0.0 определяет общедоступный API. Способ, которым номер версии
    увеличивается после того, как этот выпуск зависит от этого общедоступного API и того, как он
    изменения.

  6. Патч версии Z (x.y.Z | x> 0) ДОЛЖЕН быть увеличен, если только в обратном направлении
    введены совместимые исправления ошибок.Исправление ошибки определяется как внутреннее
    изменение, исправляющее некорректное поведение.

  7. Младшая версия Y (x.Y.z | x> 0) ДОЛЖНА быть увеличена, если новая, в обратном направлении
    совместимые функции представлены в общедоступном API. Это должно быть
    увеличивается, если какие-либо функции общедоступного API отмечены как устаревшие. МОЖЕТ быть
    увеличивается, если вводятся существенные новые функции или улучшения
    в частном коде. Он МОЖЕТ включать изменения уровня патча. Версия патча
    ДОЛЖЕН быть сброшен в 0 при увеличении младшей версии.

  8. Основная версия X (X.y.z | X> 0) ДОЛЖНА быть увеличена в обратном направлении.
    в публичный API внесены несовместимые изменения. Это МОЖЕТ также включать несовершеннолетние
    и изменения уровня патча. Патч и дополнительная версия ДОЛЖНЫ быть сброшены на 0, когда
    версия увеличивается.

  9. Предварительная версия МОЖЕТ быть обозначена добавлением дефиса и
    серия идентификаторов, разделенных точками, сразу после патча
    версия. Идентификаторы ДОЛЖНЫ содержать только буквенно-цифровые символы ASCII и дефисы.
    [0-9A-Za-z-].Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Цифровые идентификаторы ДОЛЖНЫ
    НЕ включать начальные нули. Предварительные версии имеют более низкую
    приоритет, чем соответствующая обычная версия. Предварительная версия
    указывает, что версия нестабильна и может не удовлетворять
    предполагаемые требования к совместимости, обозначенные соответствующими
    нормальная версия. Примеры: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7,
    1.0.0-x.7.z.92, 1.0.0-x-y-z.–.

  10. Метаданные сборки МОГУТ быть обозначены добавлением знака плюса и ряда точек.
    разделенные идентификаторы сразу после патча или предварительной версии.Идентификаторы ДОЛЖНЫ содержать только буквенно-цифровые символы ASCII и дефисы [0-9A-Za-z-].
    Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Метаданные сборки ДОЛЖНЫ игнорироваться при определении
    приоритет версии. Таким образом, две версии, которые отличаются только метаданными сборки,
    имеют такой же приоритет. Примеры: 1.0.0-alpha + 001, 1.0.0 + 20130313144700,
    1.0.0-beta + exp.sha.5114f85, 1.0.0 + 21AF26D3—-117B344092BD.

  11. Приоритет относится к тому, как версии сравниваются друг с другом при заказе.

    1. Приоритет ДОЛЖЕН рассчитываться путем разделения версии на основные,
      второстепенные идентификаторы, исправления и предварительные версии в указанном порядке (метаданные сборки
      не имеет приоритета).

    2. Приоритет определяется первой разницей при сравнении каждого из
      эти идентификаторы слева направо: Major, minor и patch
      версии всегда сравниваются численно.

      Пример: 1.0.0 <2.0.0 <2.1.0 <2.1.1.

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

      Пример: 1.0.0-альфа <1.0.0.

    4. Приоритет для двух предварительных версий с одинаковыми основными, дополнительными и
      версия патча ДОЛЖНА определяться путем сравнения каждого идентификатора, разделенного точкой
      слева направо, пока не будет найдена следующая разница:

      1. Идентификаторы, состоящие только из цифр, сравниваются численно.

      2. Идентификаторы с буквами или дефисами лексически сравниваются в ASCII
        Порядок сортировки.

      3. Числовые идентификаторы всегда имеют более низкий приоритет, чем нечисловые
        идентификаторы.

      4. Больший набор полей предварительного выпуска имеет более высокий приоритет, чем
        меньший набор, если все предыдущие идентификаторы равны.

      Пример: 1.0.0-alpha <1.0.0-alpha.1 <1.0.0-alpha.beta <1.0.0-beta < 1.0.0-beta.2 <1.0.0-beta.11 <1.0.0-rc.1 <1.0.0.

Грамматика форм Бэкуса – Наура для допустимых версий SemVer 

  <допустимая семерка> :: = <версия ядра>
                 | <версия ядра> "-" <предварительная версия>
                 | <ядро версии> "+" <сборка>
                 | <ядро версии> "-" <предварительная версия> "+" <сборка>

<версия ядра> :: = <основная> "." <второстепенное> "." <патч>

 :: = <числовой идентификатор>

<второстепенный> :: = <числовой идентификатор>

<патч> :: = <числовой идентификатор>

<предварительная версия> :: = <разделенные точками идентификаторы предварительной версии>

<идентификаторы предварительного выпуска, разделенные точками> :: = <идентификатор предварительного выпуска>
                                          | <идентификатор предварительной версии> "."<идентификаторы предварительного выпуска, разделенные точками>

 :: = <разделенные точками идентификаторы сборки>

<идентификаторы сборки, разделенные точками> :: = <идентификатор сборки>
                                    | <идентификатор сборки> "." <идентификаторы сборки, разделенные точками>

<идентификатор предварительной версии> :: =

.

Политика поддержки программного обеспечения ISC и нумерация версий

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

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

BIND 9

Основные версии

У нас есть четыре основных типа версий BIND 9: разработка, стабильная, расширенная поддержка (ESV) и поддерживаемая предварительная версия (также известная как «Подписка»).

Разрабатываемые версии

Мы выпускаем версии для разработки из текущей рабочей (основной) ветки. Это будут основные версии с нечетным номером, начиная с BIND 9.13.

Нет фиксированного графика выпуска второстепенных выпусков в разработке; новые минорные версии будут доступны по мере того, как новые функции или изменения будут готовы к полевым испытаниям.Второстепенные выпуски разрабатываемой версии включают новые и обновленные функции и могут быть несовместимы с предыдущими версиями. Разрабатываемые версии BIND подходят для тех, кто хочет поэкспериментировать с ISC и предоставить обратную связь о своих функциях. Не будет альфа / бета / версий-кандидатов версий для разработки, и иногда может случиться так, что недавно выпущенная вспомогательная версия заменяется очень быстро для устранения недостатка. По нашему усмотрению, мы не можем выпускать выпуски -P для версий для разработчиков с ошибками безопасности.

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

  • Текущее отделение разработки: 9,15
Стабильные версии

Исторически мы рекомендовали дождаться третьего обновления новой ветки, прежде чем развертывать ее в крупномасштабном производстве.Начиная с BIND 9.14, мы будем ежегодно публиковать новую стабильную версию. Мы стабилизируем все основные версии с четными номерами для производственного использования - например, BIND 9.14 и BIND 9.16. Каждая основная ветка будет иметь серию второстепенных выпусков, таких как BIND 9.14.0, 9.14.1 и т. Д. Второстепенные выпуски стабильной версии будут включать только исправления ошибок для максимальной стабильности.

Стабильная ветвь BIND полностью поддерживается в течение 12 месяцев, но будет EOL (End of Life), как только будет выпущена следующая стабильная версия, если не обозначена как версия с расширенной поддержкой.

  • Текущий стабильный филиал: 9,14
Версии с расширенной поддержкой (ESV)

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

Вот наш текущий BIND 9 ESV:

  • BIND 9.11 - это версия с расширенной поддержкой, которая будет поддерживаться до декабря 2021 года.

  • BIND 9.16 будет нашей следующей ESV, за ней следует BIND 9.20; каждая вторая стабильная версия после этого будет ESV.

Поддерживаемая предварительная версия (также известная как «Подписка», помеченная -S)

Выпуски

, отмеченные знаком -S, являются частью поддерживаемой предварительной версии ISC. Эти выпуски предоставляют возможность развертывания и поддержку для наших клиентов службы поддержки, чтобы получить ранний доступ к новым функциям в разработке. Редакция -S создана и доступна для поддержки подписчиков, а также может быть предложена разработчикам сообщества для тестирования и получения отзывов.Версия -S включает в себя выбранное невыпущенное программное обеспечение (новые функции и другие изменения), которое ISC считает достаточно стабильным для использования в производственной среде. Программное обеспечение, выпущенное в версиях -S, обычно будет доступно для экспериментального использования через наш публичный репозиторий кода и предназначено для возможного общедоступного выпуска. Функции версии -S могут все еще находиться в разработке и могут быть изменены или даже удалены к моменту публичного выпуска.

Выпуски -S edition активно поддерживаются и исправляются в случае уязвимостей безопасности, как и наши обычные публичные выпуски.Версия -S предлагается на тех же условиях лицензии, что и BIND 9 с открытым исходным кодом, но распространение ограничено соглашением о поддержке между ISC и подписчиком на поддержку.

План поддержки отличается от обычных выпусков:

  1. Когда мы выпускаем новый отладочный выпуск, мы делаем соответствующий -S1, который обычно включает все исправления ошибок в отладочном выпуске и обычно является расширенным набором кода в соответствующей отладочной версии.
  2. Если нам нужно сделать исправление безопасности (-P), мы делаем соответствующий -S для версии -S.Например, если бы мы выпускали 9.9.8-P1, а текущая версия выпуска S была 9.9.8-S1, соответствующая версия безопасности для выпуска -S имела бы номер 9.9.8-S2.
  3. Мы добавляем изменения (новые функции) в выпуск -S между выпусками обслуживания, которые мы не добавляем в выпуск обслуживания общедоступного выпуска.
  4. Мы не поддерживаем более одного выпуска версии -S в любой ветке.
  5. Когда мы начинаем выпускать -S версию в новой ветке, мы продолжаем поддерживать версию -S в предыдущей ветке еще шесть месяцев для поддержки миграции.
Минимальные обновления безопасности

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

ISC DHCP

Вот наши текущие версии и даты их окончания:

  • DHCP 4.1-ESV изначально планировалось перейти на EOL в декабре 2015 года, но мы расширили его на неопределенный срок, чтобы сохранить версию с меньшим размером.
  • DHCP 4.4 - текущая версия ESV. На данный момент EOL не установлен. Мы планируем поддерживать ISC DHCP до конца 2020 года, а затем провести повторную оценку.
  • Все другие версии ISC DHCP, включая 4.2.x и 4.3.x, являются EOL.

Мы приближаемся к завершению обслуживания ISC DHCP (относительно 20-летнего срока службы). Точные сроки для EOL будут зависеть от зрелости Kea и других доступных альтернатив. По мере того, как мы приближаемся к EOL для ISC DHCP, мы можем начать добавлять незначительные новые функции в точечные выпуски и делать другие исключения из наших обычных политик поддержки.

Версии с расширенной поддержкой (ESV)

Релизы

, обозначенные как ESV, являются версиями расширенной поддержки ISC. Раньше мы включали буквы ESV в название версии, но прекратили эту практику после DHCP 4.1ESV.

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

Кеа

С выпуском Kea 1.6.0 мы изменили модель выпуска Kea. Теперь у нас есть два типа основных версий Kea: Development и Stable . В любой момент времени у нас должно быть как минимум два доступных варианта: один или несколько стабильных выпусков и один выпуск для разработки.

Разрабатываемые версии

Мы выпускаем версии для разработки из текущей рабочей (основной) ветки.Это будут второстепенные версии с нечетным номером (где вторая цифра номера выпуска нечетная), начиная с Kea 1.7.0, 1.7.1, 1.7.2 и так далее, пока эта ветка не будет заменена следующей нечетной - нумерованная дополнительная версия, Kea 1.9.0.

Нет фиксированного графика выпуска выпусков для разработки; новые версии будут доступны по мере того, как новые функции или изменения будут готовы для полевых испытаний. Сопровождающие выпуски в ветках разработки будут вводить новые и обновленные функции и могут быть несовместимы с предыдущими версиями.Разрабатываемые версии Kea подходят для тех, кто хочет поэкспериментировать с ISC и предоставить обратную связь, но не рекомендуются для производственного использования. Не будет альфа / бета / версий-кандидатов версий для разработки, и иногда может случиться так, что недавно выпущенная вспомогательная версия заменяется очень быстро для устранения недостатка. По нашему усмотрению, мы не можем выпускать выпуски исправлений для версий для разработчиков с ошибками безопасности.

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

Стабильные версии

Начиная с Kea 1.6, все младшие версии с четными номерами (где вторая цифра номера версии четная) для производственного использования - например, Kea 1.6 и Kea 1.8 будут стабильными версиями. Каждая из этих веток будет иметь серию отладочных выпусков, таких как Kea 1.6.1, 1.6.2 и т. Д. Сопровождающие выпуски стабильной версии будут включать только исправления ошибок для максимальной стабильности.

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

  • Kea 1.3 был EOL в декабре 2018 года.
  • Kea 1.4 был EOL в августе 2019 года (после выпуска Kea 1.6).
  • Kea 1.5 будет поддерживаться до выпуска Kea 1.8.
  • Kea 1.6 будет стабильной версией, которая будет поддерживаться в течение шести месяцев после выпуска Kea 1.8 или до выпуска Kea 2.0, в зависимости от того, что наступит раньше.
  • Kea 1.7 будет версией для разработчиков, поддерживаемой до выпуска Kea 1.9.
  • Kea 1.8 станет следующей стабильной версией после 1.6.

Прочие руководящие принципы общей политики

Условия поддержки

Standard не распространяются на версии для разработчиков, поддерживаемую предварительную версию или альфа-, бета-версии и версии-кандидаты (RC).Обычно это недолговечные релизы.

.

No related posts.

Share :

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *