Обновление Unity-проекта: копия, зависимости и проверка сборки
Обновляйте Unity-проект на отдельной проверенной копии или в контролируемом состоянии системы версий. Установка нового Editor — только начало: нужно проверить пакеты, скрипты, рендеринг и сборку для целевой платформы. Возможность открыть сцену не доказывает успешную миграцию.
Материал опирается на документацию Unity 6.0, ветка 6000.0. Это не утверждение, что данная версия сейчас самая новая, и не рекомендация обновлять работающий проект ради номера. Инструкция помогает организовать переход, а не обещает автоматическую совместимость всех ассетов.
Сначала решите, зачем нужен переход
В Upgrade your Unity project Unity предлагает оценить преимущества относительно трудозатрат. Для крупного проекта с плагинами и нестандартными шейдерами цена миграции может быть значительной.
Запишите исходную и целевую версии Editor, целевые платформы, используемый render pipeline, критические пакеты и ожидаемую пользу. Проверьте документацию поставщиков сторонних компонентов. Наличие новой версии ассета в магазине само по себе не доказывает совместимость с нужным Editor и вашим проектом.
Не планируйте эксперимент прямо перед обязательной выдачей сборки. Сначала обеспечьте возможность получить рабочий результат старой версией.
Подготовьте обратимую исходную точку
Сохраните проект и закройте Editor перед ручным копированием. Создайте полный понятный снимок в системе контроля версий либо копию исходной папки в другое место. Убедитесь, что критические исходники и настройки действительно попали в резервирование, а не только открытые сцены.
Unity рекомендует контроль версий; при ручной копии позволяет исключить автоматически восстанавливаемую Library для экономии места. Это не разрешение выбрасывать Assets, Packages или ProjectSettings. Если нужен отдельный разбор импортного кэша, используйте руководство по Library, не смешивая его с решением о переходе версии.
Сделайте исходную контрольную сборку и короткий список проверяемых функций. Если она уже не компилируется, сначала установите причину: иначе старую ошибку легко приписать обновлению.
Читайте руководства по пути перехода
Общий раздел Upgrade Unity советует читать руководства в порядке выпусков, а рекомендуемая практика миграции — последовательный переход между основными версиями. Прямой скачок с очень старого проекта увеличивает число одновременно возникающих изменений.
Например, руководство Unity 6.0 описывает переход с 2022 LTS. Его основной охват связан с Built-In Render Pipeline; для URP и HDRP есть собственные руководства. Нельзя считать прочитанную страницу универсальным списком изменений всех версий пакетов.
Подготовьте совместимые версии зависимостей отдельным изменением. Не ставьте максимальный номер каждого пакета вслепую: сначала проверьте требования к Editor и платформе. Запишите принятые версии, чтобы другой участник мог повторить переход.
Откройте только рабочую копию новым Editor
Через Unity Hub установите целевую версию Editor и необходимые модули платформ, соответствующие проекту. Не удаляйте старую рабочую установку до завершения проверки.
В Projects проверьте путь к подготовленной копии, затем выберите нужную Editor Version. Руководство Unity описывает подтверждение Change version и предупреждение о несовпадающей версии. Это момент изменения проекта, а не безопасный просмотр без записи.
Дождитесь обработки проекта. Если предлагается Safe Mode из-за ошибок компиляции, используйте его для разбора Console: Unity рекомендует этот режим как среду исправления ошибок без ожидания полного импорта остального проекта.
Не пытайтесь лечить каждую ошибку удалением Library или открытием той же изменённой папки старым Editor. Для сравнения и возврата у вас должна оставаться отдельная исходная точка.
Исправляйте причины по категориям
Разделите сообщения Console хотя бы на три группы: несовместимый пользовательский код/API, неподходящая зависимость и изменения рендеринга или платформы. Сначала решайте первичные ошибки компиляции; десятки последующих сообщений могут быть их следствием.
Проверьте пользовательские шейдеры, материалы и важные сторонние ассеты. Если появилось розовое изображение, это ещё не доказательство недостатка VRAM: сначала проверьте совместимость pipeline и шейдера с целевой версией.
После каждого логического исправления сохраняйте отдельное понятное изменение. Так проще отличить автоматическое обновление файлов от вашей ручной правки и вернуть неудачный шаг без потери остального результата.
Проверьте Player, а не только сцену Editor
Пройдите основные функции: загрузка сцен, ввод, UI, сохранения, звук и критические игровые системы. Особое внимание уделите изменениям, перечисленным в upgrade guide, и компонентам сторонних авторов.
Выполните сборку для нужной платформы и запустите её в целевой среде. Для мобильного или Web-проекта наличие desktop-запуска не является достаточной проверкой. Сравните изображение и поведение с сохранённым исходным результатом.
Если оцениваете производительность, сравнивайте одинаковую сцену, настройки и тип сборки, учитывая различие профилирования Editor и Player. Новый импорт и первый запуск не равны устойчивой скорости игры.
FAQ
Можно ли откатиться, просто выбрав старый Editor в Hub?
Не планируйте это как надёжное восстановление изменённого проекта. Возвращайтесь к сохранённому исходному состоянию и подходящей ему версии Editor.
Успешный API Updater гарантирует миграцию?
Нет. Даже после обновления кода остаются пакеты, данные, визуальные изменения и целевые платформы, которые нужно проверять отдельно.
Нужно ли обновлять каждый проект немедленно?
Нет. Сопоставьте необходимые исправления и функции с риском и стоимостью перехода. Рабочая резервная точка важнее самого факта установки нового Editor.