Предложение WordPress по приведению цикла выпуска в соответствие с отраслевым стандартом

Вчера Франческа Марано открыла предложение об изменении фаз основного цикла выпуска WordPress. Это было резюме дискуссии, начатой ​​в октябре 2020 года. Цель состоит в том, чтобы привести фазы платформы в соответствие с более крупным отраслевым стандартом разработки.

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

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

Однако это предложение состоит из двух частей. Простое переименование фаз не меняет принцип работы цикла выпуска. Чтобы строго следовать стандарту, WordPress также должен измениться, когда код будет зафиксирован.

Как справиться с бета-фазой

Есть один спорный момент относительно того, как вести себя на стадии бета-тестирования. Стандарт не требует никаких дополнительных изменений кода, кроме новых исправлений ошибок, представленных ранее в цикле. Для проекта WordPress это создает проблему.

WordPress в этом году исполнится 18 лет. За прошедшие годы в нем накопилось множество старых ошибок. Они часто исправляются на более поздних этапах цикла, иногда на стадии бета-тестирования. Эти старые ошибки, возможно, не были частью этапа предварительного планирования, но означает ли это, что они должны подождать, пока не появится следующий выпуск? Строго следуя предложению, их следует приостановить.

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

«Я беспокоюсь, что мы не оставляем места для старых ошибок, не относящихся к запланированным функциям в выпуске», – написала Джозефа Хаден в комментарии к первоначальному обсуждению . «Я также обеспокоен тем, что, вызывая жесткую заморозку ранее в процессе, мы слишком сужаем окно для включения функций. Мне не нравится сейчас ограничиваться описанием конкретных ошибок, поскольку это исключает многих наших добровольных участников. Труднее работать над функциями, поскольку они сложны и быстро меняются, а старые ошибки предоставляют больше возможностей для случайных участников ».

С другой стороны, существует вероятность того, что исправление ошибки может привести к появлению новых, непредвиденных ошибок. Чем позже он будет добавлен во время бета-тестирования, тем меньше вероятность того, что такие ошибки будут замечены до фазы общего выпуска. Ожидание следующего цикла дает больше времени для тестирования.

Одним из преимуществ этой системы является то, что во время бета-тестирования почти не будет появляться новых ошибок. Это позволило бы волонтерам направить больше усилий на тестирование и исправление проблем, возникших в альфа-версии.

WordPress всегда шёл в такт собственному барабану. Он может более точно следовать стандартам, освобождая при этом от строгих ограничений, когда это имеет смысл для проекта. Исправления ошибок на стадии бета-тестирования, не предназначенные для конкретной версии, можно было обрабатывать в индивидуальном порядке. У нас есть люди на руководящих должностях, которые способны делать эти звонки, когда они возникают. Благодаря автоматическим обновлениям для второстепенных выпусков меня меньше беспокоят ошибки на поздней стадии.

Тоня Морк предложила два решения для продолжения работы над дефектами во время цикла выпуска и в течение всего цикла выпуска. Оба потребуют, чтобы WordPress был разветвлен в бета-версии, что предоставит участникам возможность продвигать исправление ошибок.

Первое предложение призывает к более раннему замораживанию функций, обеспечивая за две или три недели до начала бета-версии 1. Этот период в конце альфа-фазы будет посвящен исключительно устранению дефектов.

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

Это второе решение также согласуется с мыслями Йоста де Валка о работе с дефектами. «Я думаю, мы должны просто разветвляться пораньше и оставить багажник открытым для нормального бизнеса», – сказал он по поводу предложения . «Таким образом, над всем можно работать постоянно, но это не будет включено в следующий выпуск, в зависимости от того, когда вы его зафиксируете. Ничего страшного, все известные мне в мире программы с открытым исходным кодом работают так же, кроме WordPress ».

Многим разработчикам плагинов и тем уже трудно успевать за изменениями, внесенными на этапах бета-тестирования или подготовки к выпуску. Наличие четкой и определенной точки, в которой происходят изменения, принесет пользу экосистеме расширений, а также поможет конечным пользователям в долгосрочной перспективе. Это второе решение сделает это.

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

Комментарии по предложению открыты до 20 января, прежде чем перейти к окончательному решению.

Следующее предложение: семантическое версионирование , кто угодно? Кто угодно? Эта штука включена?