Текст и данные · Инструкция
yarn version --deferred отложить bump версии
`yarn version <strategy> --deferred` записывает решение о будущем повышении версии, но не применяет bump немедленно. Это удобно, когда изменение кода и решение о semver должны попасть в PR, а фактическое обновление версий выполняется централизованно на релизном этапе через `yarn version apply`.
Короткий ответ
`yarn version <strategy> --deferred` записывает будущий bump без немедленного изменения версии; накопленные записи применяются позже через `yarn version apply`.
Что меняют deferred versioning и yarn version apply
Отложенный режим разделяет решение о semver-изменении и фактический релизный bump. Поддерживаются стратегии major/minor/patch и prerelease; `--all` и `--recursive` расширяют охват workspaces. При `version apply` Yarn применяет сохранённые решения и может обновлять связанные `workspace:` диапазоны.
Совет: Deferred bump ценен тем, что решение о версии ревьюится рядом с кодом, хотя сама версия меняется позже.
Как выполнить задачу и не сломать semver
- Шаг 1: Определите semver-стратегию по изменению публичного API, а не по размеру коммита.
- Шаг 2: В нужном workspace выполните `yarn version patch --deferred` или другую обоснованную стратегию.
- Шаг 3: Закоммитьте deferred-запись вместе с изменением кода и проверьте конфликты с другими release-записями.
- Шаг 4: В релизном шаге выполните `yarn version apply`, просмотрите итоговые manifests и затем запускайте публикационные проверки.
Контроль отложенного изменения версии
- Для изменённого workspace выбрана обоснованная semver-стратегия.
- После команды версия в manifest не выдана за уже применённый bump.
- Deferred-запись попала в тот же PR/коммит, что и изменение кода.
- Перед релизом просмотрен набор всех отложенных bump, а не только один workspace.
- После `yarn version apply` версии и связанные manifests проверены до шага публикации.
Как встроить deferred bump в релизный процесс
Deferred-запись имеет смысл хранить в Git вместе с изменением, которое требует новой версии. На ревью проверьте стратегию `patch`, `minor` или `major` по совместимости публичного API, а не по размеру коммита. Перед релизом соберите все отложенные решения, примените их одной контролируемой командой и только затем просматривайте итоговые версии workspace. Если команда `apply` даёт неожиданный bump, остановитесь до публикации: это может означать конфликт нескольких deferred-решений или ручное изменение версии, сделанное параллельно. Отложенный bump особенно полезен, когда версия должна попасть в changeset-подобный процесс вместе с другими изменениями, а не отдельным коммитом.
Предупреждение: Не запускайте публикацию сразу после `apply`: сначала просмотрите manifests и итоговый diff.
Когда deferred bump может запутать релиз
Не смешивайте deferred-запись с ручным редактированием версии того же workspace без проверки: это усложняет применение и может вызвать конфликт стратегии.
Как завершить отложенный bump без сюрпризов
Процесс настроен правильно, если разработчик может отложить решение о версии в PR, а релизный шаг воспроизводимо применяет накопленные bump перед публикацией. Не смешивайте этот поток с ручным редактированием версии в тех же workspace: иначе невозможно однозначно понять, какое изменение должно было определить итоговый semver.
Важно: Критерий успеха — один понятный источник решения о версии для каждого релизуемого workspace.
Что учитывать
Не смешивайте deferred-запись с ручным редактированием версии того же workspace без проверки: это усложняет применение и может вызвать конфликт стратегии.
Источники и проверка
Фактическая часть сверена по первичным источникам (в т.ч. yarn version). Пример и формулировки — редакция N1RO на 2026-09-23.