JEP 3: JDK Release Process

Аннотация

Определить процесс, по которому участники сообщества OpenJDK готовят функциональные выпуски JDK по фиксированному графику и с коротким циклом.

Краткая справка

Эта таблица приведена здесь для удобства. Используемые в ней термины определены ниже.

	Кандидаты	Исправить	Исключить	Отложить	Улучшения?
RDP 1	Текущие P1–P3 Запланированные P1–P3	Текущие P1–P3 Запланированные P1–P3, если есть время Изменения документации/тестов P1–P5	Все P4–P5 Запланированные P1–P3	Текущие P1–P2, с одобрения	С одобрения
RDP 2	Текущие P1–P2 Запланированные P1–P2	Текущие P1–P2, с одобрения Изменения документации/тестов P1–P5	Все P3–P5 Запланированные P1–P2	Текущие P1–P2, с одобрения	С одобрения
RC	Текущие P1 Запланированные P1	Текущие P1, с одобрения	Все P2–P5 Запланированные P1	Текущие P1, с одобрения	Нет

Обзор

Текущая разработка JDK ведётся в основном репозитории проекта JDK, openjdk/jdk. Этот репозиторий всегда открыт для новой работы.

Каждые шесть месяцев, в июне и декабре, мы начинаем цикл выпуска следующего функционального выпуска JDK, далее именуемого JDK $N. Мы создаём ответвление основного репозитория — репозиторий стабилизации jdk/jdk$N — и используем его для оставшейся работы, необходимой для стабилизации выпуска. Эта работа идёт в течение следующих трёх месяцев в три фазы, описанные ниже:

• Rampdown Phase One (первая фаза стабилизации) (RDP 1) [ ошибки-кандидаты ]
• Rampdown Phase Two (вторая фаза стабилизации) (RDP 2) [ ошибки-кандидаты ]
• Фаза Release Candidate (кандидат в релизы) (RC) [ ошибки-кандидаты ]

Длительность фаз может меняться от выпуска к выпуску. Например, для JDK 11 фазы длились четыре недели для RDP 1, три недели для RDP 2 и пять недель для RC.

Каждая следующая фаза сужает набор рассматриваемых нами ошибок, а действия с этими ошибками проходят всё более строгую проверку. Так в каждой фазе мы исправляем те ошибки, которые нужно исправить именно в это время. Кроме того, так мы понимаем, почему не исправляем некоторые ошибки, которые, возможно, и следовало бы исправить, но которые по веским причинам лучше оставить для будущего выпуска. Поэтому в фазах используются два процесса одобрения, также описанные ниже:

• Процесс отсрочки ошибок [ ожидающие запросы ]
• Процесс запроса на исправление [ ожидающие запросы ]

Общий набор возможностей замораживается в RDP 1. После этого момента новые JEP в выпуск не планируются.

Поздние улучшения с низким риском, которые добавляют небольшие недостающие части функциональности или повышают удобство использования, допускаются с одобрения в RDP 1 и RDP 2, особенно если они обоснованы отзывами разработчиков или поддержкой JCP EG, но планка очень высока в RDP 1 и исключительно высока в RDP 2. Запросить одобрение позднего улучшения можно через третий процесс:

• Процесс запроса на позднее улучшение [ ожидающие запросы ]

Ошибки-кандидаты

Каждая фаза строится вокруг списка ошибок-кандидатов. Ошибки-кандидаты каждой фазы имеют приоритет не ниже порога приоритета этой фазы, который начинается с P3 для RDP 1, затем повышается до P2 для RDP 2 и до P1 для RC. Каждая ошибка-кандидат — это либо

• текущая ошибка, обнаруженная в сборке Early Access (ранний доступ) JDK $N и заявленная для этого выпуска через поле Affects Version, либо

• запланированная ошибка, заявленная для какого-либо прошлого выпуска, но запланированная через поле Fix Version на JDK $N.

Критическая ошибка — это текущая ошибка с приоритетом P1 или P2 (в RDP 1 и RDP 2) либо P1 (в RC).

Запросы для ошибок-кандидатов каждой фазы определены в JBS. Кратко:

	Приоритет	Критические	Запрос
RDP 1	≥ P3	≥ P2	openjdk.org/s/jdk-rdp-1
RDP 2	≥ P2	≥ P2	openjdk.org/s/jdk-rdp-2
RC	= P1	= P1	openjdk.org/s/jdk-rc

Действия в фазе

В каждой фазе мы стремимся исправить, исключить или отложить каждую ошибку-кандидат. Если вы отвечаете за ошибку-кандидат, выполните одно из следующих действий:

• Исправить Если ошибка текущая, разработайте исправление и либо интегрируйте его, когда оно будет готово (в RDP 1), либо запросите одобрение на интеграцию через процесс запроса на исправление (RDP 2 и RC). В RDP 1, если ошибка запланированная и позволяет время, разработайте и интегрируйте исправление, когда оно будет готово.

• Исключить Если ошибка запланированная, но не критическая, исключите её из выпуска одним из способов:

  • очистите поле Fix Version, или

  • установите в поле Fix Version значение $N + 1, если вы достаточно уверены, что исправите ошибку в следующем выпуске, или

  • установите в поле Fix Version значение tbd, если вы определили, что исправление не попадёт в следующий выпуск, но может попасть в какой-то более поздний.

• Отложить Если ошибка критическая, но её нельзя исправить вовремя или исправлять её слишком рискованно, запросите одобрение на отсрочку ошибки из выпуска через процесс отсрочки ошибок.

В любом случае не меняйте приоритет ошибки ради того, чтобы убрать её из списка кандидатов. Приоритет ошибки должен отражать важность её исправления независимо от конкретного выпуска — такова стандартная практика JDK уже много лет.

Ошибки, не являющиеся кандидатами

Если вы отвечаете за ошибку, не являющуюся кандидатом, но запланированную на JDK $N через поле Fix Version, исключите её: очистите это поле, установите в нём значение $N + 1 или значение tbd, как описано выше. Откладывать такие ошибки через процесс отсрочки не нужно.

Ошибки и улучшения в тестах и документации

Ошибки и улучшения любого приоритета, которые затрагивают только тесты, списки проблемных тестов или документацию, можно обрабатывать в RDP 1 и RDP 2. Запрашивать одобрение для интеграции такого изменения не нужно, но обязательно убедитесь, что у задачи есть метка noreg-self или noreg-doc, в зависимости от случая.

Интеграция исправлений и улучшений

Большинство исправлений и улучшений, предназначенных для стабилизационного выпуска, применимы и к выпуску основной линии. Чтобы внести такое изменение в стабилизационный выпуск:

1. Запланируйте соответствующую задачу JBS на выпуск основной линии, сразу создайте backport этой задачи и запланируйте этот backport на стабилизационный выпуск.

2. Создайте PR для интеграции изменения в основной репозиторий.

3. Получив все необходимые одобрения, перенесите PR основной линии в репозиторий стабилизации командой Skara /backport или, если необходимо, вручную откройте backport-PR с заголовком Backport $HASH, где $HASH — хэш исходного коммита.

Все такие backport-изменения требуют повторного ревью, даже если они чистые, чтобы обеспечить стабильность. (Больше информации о работе с backport-изменениями есть в Developers’ Guide.)

Некоторые исправления и улучшения относятся только к стабилизационному выпуску и неприменимы к выпуску основной линии. Интегрируйте такие изменения непосредственно в репозиторий стабилизации.

Чтобы ни один backport не был пропущен, перед фазами RDP 2 и RC участникам разработки JDK будет напоминаться о необходимости проверить исправления ошибок, которые интегрированы в основной репозиторий, но не перенесены в репозиторий стабилизации. Могут пригодиться следующие запросы JBS:

• Исправления ошибок, не перенесённые из основной линии
• Мои исправления ошибок, не перенесённые из основной линии

Процесс переноса исправления ошибки на более поздний срок

Этот процесс действует с RDP 1 до конца выпуска.

Запрос на перенос

Если вы отвечаете за ошибку, которая не будет исправлена на текущей фазе разработки, вы можете запросить перенос следующим образом. Добавьте в задачу JBS комментарий, первая строка которого — «Deferral Request». В этом комментарии кратко опишите причину переноса (например, недостаток времени, сложность или риск исправления и т. д.). Добавьте к задаче метку jdk$N-defer-request, подставив вместо $N фактический номер версии выпуска.

Перенос не разрешается для задач TCK, отмеченных меткой tck-red-$N, за исключением, возможно, случаев, когда речь идёт о новых тестах TCK. Перенос ошибок, которые мешают тестированию выпуска, маловероятен.

Рассмотрение запросов на перенос

Area Leads, соответствующие Group Lead и JDK Project Lead будут регулярно, несколько раз в неделю, рассматривать ожидающие запросы на перенос. Один из них выполнит одно из следующих действий:

• Одобрит запрос, добавив метку jdk$N-defer-yes. (Добавлять комментарий, фиксирующий это одобрение, не нужно.)

• Отклонит запрос, добавив метку jdk$N-defer-no вместе с комментарием, в котором описана причина этого решения.

• Запросит дополнительную информацию, добавив метку jdk$N-defer-nmi («nmi» = «needs more information», «нужно больше информации») вместе с комментарием, в котором описано, какая информация требуется.

В любом случае не удаляйте метку jdk$N-defer-request.

Запрос JBS для ожидающих запросов: openjdk.org/s/jdk-defer-pending

Реакция на действия по вашему запросу на перенос

• Если вас попросили предоставить дополнительную информацию по запросу на перенос, сделайте это в новом комментарии к задаче, а затем удалите метку jdk$N-defer-nmi, чтобы рецензенты видели, что запрос готов к повторному рассмотрению.

• Если ваш запрос одобрен, никаких дальнейших действий с вашей стороны не требуется.

Процесс запроса на исправление

Этот процесс действует с RDP 2 до конца выпуска.

Запрос разрешения на интеграцию исправления

Прежде чем тратить много времени на исправление ошибки P1 или P2, посоветуйтесь с Group Lead или Area Lead в соответствующей рассылке, чтобы убедиться, что исправлять эту ошибку в данном выпуске действительно разумно.

Когда вы уверены в своём исправлении, добавьте в соответствующую задачу JBS комментарий, первая строка которого — «Fix Request». (Не нужно ждать, пока само исправление будет одобрено для интеграции соответствующими Reviewer.) В этом комментарии кратко опишите, почему важно исправить эту ошибку, объясните суть исправления, оцените его риск, опишите его покрытие тестами и укажите, кто его проверил. Если для исправления есть pull request или webrev, включите в комментарий ссылку на него; в противном случае приложите патч с исправлением к задаче JBS. Добавьте к задаче метку jdk$N-fix-request, подставив вместо $N фактический номер версии выпуска.

Всегда добавляйте комментарий и метку к задаче JBS основной линии; не добавляйте их к задаче backport.

Рассмотрение запросов на исправление

Area Leads, соответствующие Group Lead и JDK Project Lead будут регулярно рассматривать ожидающие запросы на исправление: сначала не реже раза в неделю, а по мере приближения даты GA — чаще. В срочной ситуации вы можете напрямую связаться с подходящим рецензентом, чтобы попросить о быстром рассмотрении.

Рецензент выполнит одно из следующих действий:

• Одобрит запрос, добавив метку jdk$N-fix-yes вместе с комментарием, фиксирующим одобрение, первая строка которого — «Fix request approved».

• Отклонит запрос, добавив метку jdk$N-fix-no вместе с комментарием, в котором описана причина этого решения и первая строка которого — «Fix request rejected».

• Запросит дополнительную информацию, добавив метку jdk$N-fix-nmi («nmi» = «needs more information», «нужно больше информации») вместе с комментарием, в котором описано, какая информация требуется, и первая строка которого — «Fix request NMI».

В любом случае не удаляйте исходную метку jdk$N-fix-request.

Запрос JBS для ожидающих запросов на исправление: openjdk.org/s/jdk-fix-pending

Реакция на действия по вашему запросу на исправление

• Если вас попросили предоставить дополнительную информацию по запросу на исправление, сделайте это в новом комментарии к задаче, а затем удалите метку jdk$N-fix-nmi, чтобы рецензенты видели, что запрос готов к повторному рассмотрению.

• Если ваш запрос одобрен, завершите исправление и интегрируйте его.

• Если ваш запрос отклонён, вы можете обжаловать это решение у Project Lead.

В любом случае не удаляйте исходную метку jdk$N-fix-request.

Процесс запроса на позднее улучшение

Этот процесс действует с RDP 1 до конца RDP 2.

Запрос разрешения на позднее улучшение

Если вы хотите интегрировать улучшение в RDP 1 или RDP 2, вы можете запросить разрешение следующим образом. Добавьте в соответствующую задачу JBS комментарий, первая строка которого — «Late Enhancement Request». В этом комментарии опишите уровень риска, дайте краткое обоснование, по возможности с цитатами реальных отзывов разработчиков, и укажите вашу наиболее точную оценку даты, к которой вы его интегрируете. Добавьте к задаче метку jdk$N-enhancement-request, подставив вместо $N фактический номер версии выпуска.

Всегда добавляйте комментарий и метку к задаче JBS основной линии; не добавляйте их к задаче backport.

Улучшения тестов и документации во время RDP 1 и RDP 2 не требуют разрешения, если соответствующие задачи отмечены меткой noreg-self или noreg-doc, в зависимости от случая.

Рассмотрение запросов на улучшение

JDK Project Lead или, в случае его отсутствия, его заместитель будет регулярно, несколько раз в неделю, рассматривать ожидающие запросы на улучшение. Он выполнит одно из следующих действий:

• Одобрит запрос, добавив метку jdk$N-enhancement-yes вместе с комментарием, фиксирующим одобрение, первая строка которого — «Late enhancement approved».

• Отклонит запрос, добавив метку jdk$N-enhancement-no вместе с комментарием, в котором описана причина этого решения и первая строка которого — «Late enhancement rejected».

• Запросит дополнительную информацию, добавив метку jdk$N-enhancement-nmi («nmi» = «needs more information», «нужно больше информации») вместе с комментарием, в котором описано, какая информация требуется.

В любом случае не удаляйте метку jdk$N-enhancement-request.

Запрос JBS для ожидающих запросов: openjdk.org/s/jdk-enhancement-pending

Реакция на действия по вашему запросу на улучшение

• Если вас попросили предоставить дополнительную информацию по запросу на улучшение, сделайте это в новом комментарии к задаче, а затем удалите метку jdk$N-enhancement-nmi, чтобы рецензенты видели, что запрос готов к повторному рассмотрению.

• Если ваш запрос одобрен, укажите в поле срока выполнения задачи ожидаемую дату завершения.

История

• 2023/6/1 — Переработано: описан подход «стабилизация через backport», принятый в JDK 21 (предложение).

• 2023/12/20 — Переработаны инструкции по интеграции: рекомендуется сразу создавать задачи backport, чтобы не упустить из виду ошибки-кандидаты (предложение).

• 2024/12/1 — Неработающие ссылки j.mp заменены ссылками openjdk.org/s.