Перейти к содержимому

Приветствуем вас на 99Fps.Ru - Дом, милый дом!
Зарегистрируйтесь сейчас, чтобы получить доступ ко всем нашим функциям. После регистрации и входа в систему Вы сможете создавать темы, отвечать на существующие темы, использовать систему репутации ввиде бананчиков, получить свой собственный мессенджер, размещать обновления статусов, управлять профилем и многое другое. Если у вас уже есть учетная запись, Войдите - Регистрация нового аккаунта


Фотография

Семантическое версионирование


  • Авторизуйтесь для ответа в теме
В теме одно сообщение

#1
Eriurias

Eriurias
  • Пользователи
  • 109 сообщений





Семантическое версионирование



[FONT='times new roman']Добрый день, дорогие пользователи нашего всеми любимого проекта 99FPS.RU. [/FONT]

[FONT='times new roman']Сегодня я бы хотел Вас познакомить с таким понятием в мире программирования и другим управлением процесса разработкой, как «Семантическое версионирование» («Semantic Versioning»).[/FONT]

[FONT='times new roman']Версия хорошего продукта, имеющее публичное API, должно состоять из трех подверсий (например, 1.0.0), которые имеют свое название. [/FONT]

[FONT='times new roman']Структура версионирования выглядит следующим образом:[/FONT]

  • [FONT='times new roman']«Мажорная версия (Major version)»;[/FONT]
  • [FONT='times new roman']«Минорная версия (Minor version)»;[/FONT]
  • [FONT='times new roman']«Патч версия (Patch version)».[/FONT]

Мажорная версия [FONT='times new roman']увеличивается при изменениях API, нарушающих совместимость с предыдущей версией («Обратная совместимость/Backwards-Compatible»[/FONT][FONT='times new roman']).[/FONT]

[FONT='times new roman']Минорная версия увеличивается при добавлении нового функционала, не нарушающего совместимость с предыдущей версией.[/FONT]

[FONT='times new roman']Патч версия увеличивается при исправлениях, совместимых с предыдущей версией, опять же, обратная совместимость.[/FONT]

[FONT='times new roman']Таким образом, система версионирования позволяет нам систематично и организованно определять версии наших продуктов, а не от балды придумывать циферки. Нет желания более подробно это разъяснять, моей целью было подчеркнуть самое важное. Если у вас есть желание прочитать "много буков", то можете также продолжить чтение этой маленькой статьи и познакомиться с официальной спецификацией (что знать в принципе не обязательно, за исключением первых двух пунктов).[/FONT]
  • 1


Если человека нельзя вылечить, это не значит, что ему нельзя помочь. © Google.


#2
Eriurias

Eriurias
  • Пользователи
  • 109 сообщений





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

 

  • ПО, использующее Семантическое Версионирование, должно объявить публичный API. Этот API может быть объявлен самим кодом или существовать строго в документации. Как бы ни было это сделано, он должен быть точным и исчерпывающим.
  • Обычный номер версии ДОЛЖЕН иметь формат X.Y.Z, где X, Y и Z — неотрицательные целые числа и НЕ ДОЛЖНЫ начинаться с нуля. X — мажорная версия, Y — минорная версия и Z — патч-версия. Каждый элемент ДОЛЖЕН увеличиваться численно. Например: 1.9.0 ->1.10.0 -> 1.11.0.
  • После релиза новой версии пакета содержание этой версии НЕ ДОЛЖНО быть модифицировано. Любые изменения ДОЛЖНЫ быть выпущены как новая версия.
  • Мажорная версия ноль (0.y.z) предназначена для начальной разработки. Всё может измениться в любой момент. Публичный API не должен рассматриваться как стабильный.
  • Версия 1.0.0 определяет публичный API. После этого релиза номера версий увеличиваются в зависимости от того, как изменяется публичный API.
  • Патч-версия Z (x.y.Z | x > 0) ДОЛЖНА быть увеличена только если содержит обратно совместимые баг-фиксы. Определение баг-фикс означает внутренние изменения, которые исправляют некорректное поведение.
  • Минорная версия (x.Y.z | x > 0) ДОЛЖНА быть увеличена, если в публичном API представлен новый обратно совместимый функционал. Она ДОЛЖНА быть увеличена, если какой-либо функционал публичного API помечен как устаревший (deprecated). Она МОЖЕТ быть увеличена в случае реализации нового функционала или существенного усовершенствования в приватном коде. Она МОЖЕТ включать в себя изменения, характерные для патчей. Патч-версия ДОЛЖНА быть обнулена, когда увеличивается минорная версия.
  • Мажорная версия X (X.y.z | X > 0) ДОЛЖНА быть увеличена, если в публичном API представлены какие-либо обратно несовместимые изменения. Она МОЖЕТ включать в себя изменения, характерные для уровня минорных версий и патчей. Когда увеличивается мажорная версия, минорная и патч-версия ДОЛЖНЫ быть обнулены.
  • Предрелизная версия МОЖЕТ быть обозначена добавлением дефиса и серией разделённых точкой идентификаторов, следующих сразу за патч-версией. Идентификаторы ДОЛЖНЫ содержать только 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.
  • Сборочные метаданные МОГУТ быть обозначены добавлением знака плюс и ряда разделённых точкой идентификаторов, следующих сразу за патч или предрелизной версией. Идентификаторы ДОЛЖНЫ содержать только ASCII буквенно-цифровые символы и дефис [0-9A-Za-z-]. Идентификаторы НЕ ДОЛЖНЫ быть пустыми. Сборочные метаданные СЛЕДУЕТ игнорировать, когда определяется старшинство версий. Поэтому два пакета с одинаковой версией, но разными сборочными метаданными, рассматриваются как одна и та же версия. Примеры: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.
  • Приоритет определяет, как версии соотносятся друг с другом, когда упорядочиваются. Приоритет версий ДОЛЖЕН рассчитываться путём разделения номеров версий на мажорную, минорную, патч и предрелизные идентификаторы. Именно в такой последовательности (сборочные метаданные не фигурируют в расчёте). Приоритет определяется по первому отличию при сравнении каждого из этих идентификаторов слева направо: Мажорная, минорная и патч-версия всегда сравниваются численно. Пример: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. Когда мажорная, минорная и патч-версия равны, предрелизная версия имеет более низкий приоритет, чем нормальная версия. Пример: 1.0.0-alpha < 1.0.0. Приоритет двух предрелизных версий с одинаковыми мажорной, минорной и патч-версией ДОЛЖНЫ быть определены сравнением каждого разделённого точкой идентификатора слева направо до тех пор, пока различие не будет найдено следующим образом: идентификаторы, состоящие только из цифр, сравниваются численно; буквенные идентификаторы или дефисы сравниваются лексически в ASCII-порядке. Численные идентификаторы всегда имеют низший приоритет, чем символьные. Больший набор предрелизных символов имеет больший приоритет, чем меньший набор, если сравниваемые идентификаторы равны. Пример: 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.

  • 2


Если человека нельзя вылечить, это не значит, что ему нельзя помочь. © Google.





Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных