Система версий в Re-продуктах

Сообщения
505
Реакции
584
Все мы знаем типичную ошибку, возникающую при обновлении Re-продуктов, когда владелец сервера обновит одно, но забудет другое.
Выглядит в общем виде так:
ReGameDLL Api major version mismatch; expected 3, real 4
или так
[ReSemiclip]: ReGameDLL Api minor version mismatch; expected 3, real 2

Названия модулей и плагинов могут быть любые, есть общее ядро:
Api ЧТО-ТО version mismatch; expected ОДНО, real ДРУГОЕ

Решение от опытных форумчан простое: обновите все Re-продукты. Помогает в 100% случаях, однако как правило суть ошибки люди не понимают. Что имеется в виду под таинственными ЧТО-ТО, ОДНО и ДРУГОЕ? major, minor, цифры какие-то.

Начнём с версий Re-продуктов.
Посмотрите на ReHLDS, REGameDLL, ReAPI, Metamod-r.
Номер версии представляет собой 4 числа, разделённые точками. В случае с AmxModX чисел 3.
Общий вид представим как A.B.C.D

versions1.png

При обновлениях числа меняются. Обычно D, реже - С, ещё реже - B и совсем редко A.
Это связано с общепринятой системой версий, называемой Семантическим Версионированием.

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

При разработке любого крупного проекта мы вынуждены подключать сторонние библиотеки, таковы реалии современного программирования. Чем больше проект - тем больше различных модулей требуется для его функционирования. В сложной системе выпуск новой версии основного продукта часто влечёт обновление старых версий подключенных библиотек и наоборот. Если спецификация подключаемых библиотек и вашего продукта свободна(называй как хочешь, делай что хочешь), то рано или поздно разработчики начнут сталкиваться с постоянными несоответствиями версий, пойдут отказы в работе. Ведь толком неясно что обновилось, когда, в какой версии. Начинаешь судорожно пробовать всё подряд. Этот модуль не подходит, этот ещё хуже. Опа, вон тот подошёл, зато почему-то отвалился другой и программа работает как-то не так. Ковыряем дальше.
Это называется "ад зависимостей"(dependency hell).
В качестве решения придуман набор правил, которые определяют номер версии.

Формат A.B.C.D следует понимать как Мажорная версия.Минорная версия.Патч.Минорный патч
Сперва выпускается версия 0.B.C.D
0 говорит, что релиза нет, продукт в разработке. Всё может измениться в любой момент, API нестабилен.
Наступает релиз.
Версия 1.0.0.0 определяет публичный API. После этого релиза номера версий A, B, C и D увеличиваются в зависимости от того, как изменяется публичный API.

Числа увеличиваются по правилам:
  1. МАЖОРНАЯ версия A , когда сделаны обратно несовместимые изменения API.
  2. МИНОРНАЯ версия B, когда добавлен новый функционал, не нарушая обратной совместимости.
  3. ПАТЧ С, когда делаются обратно совместимые исправления.
  4. Касательно МИНОРНОГО ПАТЧА D правила нет, так как обновление не влияет на совместимость с другими продуктами. Просто удобный номер, определяющий порядок очередной микро-версии.
Вернёмся к ошибке
ReGameDLL Api major version mismatch; expected 3, real 4

Теперь мы знаем что от нас хочет сервер. Ожидается мажорная версия 3, а у нас установлена 4.
Кем ожидается? Очевидно тем, кто использует API ReGameDLL.
Мажорная версия обозначена здесь A.B.C.D
Выход: откатить ReGameDLL(что не есть хорошо) либо обновить остальные компоненты, с ним связанные(верное решение).

[ReSemiclip]: ReGameDLL Api minor version mismatch; expected 3, real 2
а вот тут ясно, что ReSemiclip требует иную версию ReGameDLL.
У нас минорная 2, а нужна 3.
Минорная версия обозначена здесь A.B.C.D

Обновляем свою A.2.C.D до A.3.C.D, перезапускаем сервер, радуемся.

Подробно про семантическое версионирование можно узнать здесь или в Вики
Все права на статью принадлежат Dev-CS.ru TEAM. При копировании материала активная ссылка обязательна.
 
Последнее редактирование:
Сообщения
505
Реакции
584
Перенесено в общий раздел.
 

Пользователи, просматривающие эту тему

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