WordPress 7.1が公開されたのは8月19日だった。それからひと月も経たないうちに、次に来る修正版である7.1.1の日程が公表されている。9月2日に出た告知には、バグを仕分ける作業日の日取りから一般公開の予定日までが一覧で並んでいる。大きな更新のニュースは目にしても、その後始末の予定まで公開されていることは意外と知られていない。

修正版の日程は前もって示される

公表された予定では、9月3日と4日、8日、9日、15日にバグの棚卸しにあたる作業日が置かれ、9月10日にリリース候補版、9月17日に7.1.1の一般公開という並びになっている。時刻はいずれも協定世界時での目安で、実際の時間は担当者の都合によって前後する可能性があるとも添えられている。

この予定が出る前、8月20日の時点では「9月1日から24日のあいだ」という幅のある見通ししか示されていなかった。報告されたバグの深刻さと数を見てから時期を決めるという方針があるためだ。公開後に寄せられた報告の量と深刻さから、修正版は習慣的に準備すべきだと判断された、という書き方になっている。幅のある見通しが具体的な日付へ絞り込まれていく過程が、そのまま外から追える状態に置かれている。

入るものと入らないものが決まっている

7.1.1はバグ修正だけの修正版だと明記されている。対象になるのは7.1の開発期間中に持ち込まれた不具合か、7.1の締め切りの時点で意図的に先送りされた項目に限られる。新しい機能はここには入らない。何が候補になっているかは、不具合の追跡システムの一覧や編集画面まわりの作業ボードから追えるようになっている。

7.1は機能の追加が多い版だった。表示まわりでは画面幅ごとの指定が入り、切り替えの基準となる幅をテーマ側で決められるようになっている。投稿の編集画面も枠内で読み込む形に一本化された。触る範囲が広い更新のあとに報告が集まりやすいのは自然なことで、修正版の枠が早めに用意されるのはその裏返しでもある。

目を引くのは、9月8日の作業日に7.1.2の枠を開き、そこで一部の項目を先送りすると最初から告知している点だ。締め切りに間に合わないものは次に回すという判断が、あらかじめ日程に組み込まれている。直すべきものを溜め込まず、期限で区切って次の枠へ送る。規模の小さい制作現場の案件管理にも、そのまま持ち込める考え方だと思う。

少人数で回っている工程

大型更新の体制と比べると、修正版のチームはかなり小さい。担当者は1人から3人程度になることが多いと説明されている。仕事の中身は、コミッターや各機能の担当と連携してバグを仕分けること、公開のお知らせを書くこと、公開当日の作業を準備して進めること、そして次回のために手順書を更新することとされている。

大型更新に関わった人がそのまま残ることが多いものの、必須ではなく、大型更新の経験がなくても志願できると書かれている。バグの棚卸しは公開された相談部屋で行われ、自分で棚卸しの場を開いてもよいとされている。翻訳が足りていない言語があるという案内も添えられていた。ふだんは使うだけの側から見ると、公開までの手順がここまで読める状態になっていること自体が珍しい。

受け取る側の準備

小さな更新は自動で当たる設定のまま運用しているサイトが多いはずだ。実際、7月17日に出た7.0.2では深刻度の高い問題が含まれていたため、影響を受けるバージョンに対して強制的な更新が実施されている。8月6日の7.0.3では、さらに十数件の修正が入った。放っておいても当たる前提で組まれている以上、現場の役目は「更新するかどうか」ではなく「当たったあとで崩れていないか」を見に行くほうへ寄る。

更新の当たり方はサイトごとに違う。保守を受けている環境では自動更新を止めている場合もあるし、逆に管理する側で一括して当てている場合もある。どちらであっても、修正版が出る日が前もって分かっていれば、確認の予定をその前後に寄せておける。

その意味で、リリース候補版が出る9月10日から一般公開までのおよそ一週間は、手元のプラグインやテーマを新しい版に当てて試せる期間でもある。7.1では、投稿一覧の表で見出しにあたるセルの位置が長年の形から変わるといった、地味ながら影響範囲の広い変更も入っていた。修正版でどこが動くのかを先に眺めておけば、公開後に原因を探して回る時間は減らせる。日々の運用を預かる立場なら、公開日の前後で表示と管理画面を一度通しで確認しておくくらいの構えでちょうどいい。