Выберите файл и прочитайте изменения
В консоли старого сервера выполните version и сохраните ответ; в терминале запуска — java -version. Скачайте целевой JAR с загрузок Paper и сохраните его как paper-next.jar вне runtime. Прочитайте инструкцию обновления Paper и страницы выпусков каждого критического плагина: одного совпадения версии Minecraft мало.
Сверьте требования Java: Paper 1.20–1.21.11 использует Java 21, 26.1+ — Java 25. Перед большим переходом установите runtime с Adoptium и проверьте его из того же скрипта/службы, которым будет запускаться тест.
Создайте закрытую копию
В серверной консоли выполните stop, дождитесь завершения процесса и скопируйте весь runtime в новую папку mc-update-test. На Windows используйте копирование папки в Проводнике; в Linux для расположенного рядом runtime выполните cp -a mc-server mc-update-test. Старый сервер после согласованной копии можно снова запустить до технического окна.
В тестовой папке замените JAR целевым файлом, отключите рабочие интеграции и направьте внешние БД на отдельные копии. В server.properties задайте server-ip=127.0.0.1 и server-port=25566. Если копия содержит Geyser, отключите его JAR на время локального Java-теста либо назначьте отдельный UDP-порт.
Пройдите короткий сценарий приёмки
Из mc-update-test запустите java -Xms2G -Xmx2G -jar paper-next.jar --nogui. Найдите в logs/latest.log ошибки загрузки плагинов, миграции БД и чтения мира. В Java-клиенте нужного выпуска откройте Сетевая игра → Прямое подключение → localhost:25566.
- Откройте сундук и инвентарь с предметами, созданными до перехода: проверьте имена, зачарования и специальные свойства вашего плагина.
- Обычным аккаунтом используйте приват, дом, магазин и один игровой режим; запишите баланс до и после тестовой покупки.
- В консоли выполните
stop, затем снова запустите копию. Сравните сохранённые вещи и прогресс. При потере данных не переходите к рабочему серверу, пока причина не установлена.
Установите именно испытанный комплект
В объявленное окно остановите рабочий сервер, создайте финальный бэкап и сохраните прежний JAR под отдельным именем вне plugins/runtime-запуска. Скопируйте те же файлы и настройки, которые прошли проверку, затем запустите с whitelist и повторите критические действия.
Если нужен откат, остановите новый процесс и восстановите весь комплект данных до обновления вместе с прежними бинарниками. Мир или БД, уже преобразованные новым выпуском, не следует открывать старым JAR в надежде на обратную миграцию. Общий вход открывайте после сохранения контрольного предмета, покупки и завершения мини-игры.
Соберите таблицу совместимости до смены JAR
Запишите текущую и целевую версии ядра, Java, менеджера миров, прав, экономики, кроссплея и ключевых игровых плагинов. Для каждого найдите явное подтверждение поддержки целевого выпуска. Зелёный статус одного проекта не описывает всю сборку. Особенно внимательно проверяйте компоненты, меняющие инвентари, предметные данные и доступ к нескольким мирам.
На проверенной странице Paper для 1.20–1.21.11 указан Java 21, для 26.1+ — Java 25. Поэтому крупный переход способен требовать обновления runtime. Проверьте Java в службе или контейнере, а не только в терминале. Для собственной разработки пересоберите плагин под осознанно выбранный API и проверьте отсутствие обращения к изменённым внутренним классам.
Тот же список платформ, зависимостей и сценариев нужен для каждого обновляемого плагина. Проверка компонентов сборки.
Используйте копию с определённой точкой состояния
Сделайте согласованную копию миров и баз после штатной остановки или поддерживаемой процедуры. В тестовом экземпляре отключите рабочие уведомления, внешние платежи и реальные награды. Новый сервер не должен конкурировать с production за одну базу. Укажите отдельные порты и собственный каталог runtime, чтобы тест случайно не открыл второй доступ к тем же данным.
Сначала запустите целевой выпуск и прочитайте журнал преобразований. Затем выполните сценарии с реальными особенностями сборки: смена мира, приват, магазин, задание, вход и выход мини-игры, смерть и повторная авторизация. Один тест на пустом новом мире не обнаружит ошибки чтения старых предметов или незавершённых сессий.
Определите критерии отказа заранее
Удобно записать четыре причины отката: не загружается основной мир, теряется инвентарь, неверно меняется баланс или критический режим не завершает сессию. Дополните их особенностями своего проекта. Мелкую косметическую разницу и неисправность выдачи валюты нельзя оценивать одинаково. Критерии помогают принять решение в короткое техническое окно.
Старый JAR возвращают вместе с состоянием до преобразования, а не поверх уже изменённой базы. Полное восстановление.
Порядок активации
Не меняйте проверенный выпуск на свежий «latest» прямо перед активацией. Иначе тест относился к другому набору файлов. Сохраните манифест релиза и контрольные суммы. Конфигурационные миграции тоже должны совпадать с тестом; возвращение старого бинарника не откатывает автоматически обновлённый формат настроек.
- Согласуйте время и объявите закрытие входа.
- Остановите сервер штатно и создайте финальную точку восстановления.
- Установите проверенные артефакты, runtime и настройки.
- Запустите экземпляр и выполните короткий набор критических тестов.
- При успехе откройте вход и наблюдайте реальные игровые сценарии.
- При критическом отказе остановите новый процесс и восстановите прежний комплект данных и версий.
Наблюдение после открытия
Сравните продолжительность тиков, память и число ошибок с похожей нагрузкой до перехода. Не оценивайте производительность по пустому спавну: первые генерации новых чанков и запуск сложной фермы дают другую нагрузку. Повторите вход после мини-игры и проверку редкого сценария, который нельзя было полностью покрыть коротким окном.
Отдельно проверьте клиентов разных разрешённых версий и Bedrock, если есть Geyser. Успешный Java-вход администратора не подтверждает UDP-путь и соответствие мостов. Обновите опубликованные поддерживаемые версии только после проверки. Список на сайте, сообщение отказа и фактическая конфигурация должны согласовываться.
Если откат понадобился после открытия, учтите новый прогресс игроков: восстановление старой точки его потеряет. Поэтому критические проверки проводят до общего входа, а задержку решения ограничивают. Запишите итог перехода, обнаруженные отличия и способ следующего обновления. Это становится рабочей инструкцией, а не историей догадок.
Проверка старого предмета
До обновления подготовьте контрольный предмет с именем, зачарованиями и свойством, важным вашему плагину. После запуска целевой версии проверьте его отображение, применение и сохранение при повторном входе. Новая пустая кирка не выявит ошибки преобразования старого сложного предмета. Если свойство пропало, остановите переход и исследуйте копию до открытия общей игры.
