小さなバージョンパーサーのバグが WP Staging CLI の自己更新を壊した経緯

WP Staging CLI の v1.10.0 または v1.11.0 を使っている場合、組み込みの wpstaging update コマンドは更新の確認を拒み、「Update check skipped for development version」 と出力します。CLI はこの2つのバージョンでは自分自身をその場で更新できません。この記事では、何が問題だったのか、私たちが何を修正したのか、そして健全なインストールに戻すための一度きりのコマンドを説明します。

要点

影響を受けるバージョン：v1.10.0 と v1.11.0 のみ。復旧するには、当社の公式インストーラーを再実行してください。既存のインストールを検出し、バイナリをその場で置き換え、あなたのサイト・ライセンス・設定はそのまま残します。

Linux、macOS、WSL:

curl -fsSL https://wp-staging.com/install.sh | bash

Windows PowerShell:

irm https://wp-staging.com/install.ps1 | iex

Windows CMD:

curl -fsSL https://wp-staging.com/install.cmd -o install.cmd && install.cmd && del install.cmd

その後は v1.11.1 以降になり、wpstaging update が再び正常に動作します。

何が起きたか

アップデーターは、きれいな semver 文字列に見えないものをすべて開発ビルドとして扱い、更新の確認を静かにスキップします。意図は妥当でした：バージョンフラグなしで go run や make build を使って CLI をローカルでビルドすると、そうしなければコマンドを実行するたびに紛らわしい 「Update vX.Y.Z available (current: vdev)」 というメッセージが表示されてしまうからです。

バグの内容：私たちのリリースタグは v1.10.0、v1.11.0 などのように、先頭に v を付けてプッシュされます。しかしバージョンパーサーは、v のない 1.10.0 を要求していました。先頭の v は最初に取り除かれるはずでしたが、開発ビルドの判定が取り除きの手順より 前 に走っていました。そのため、リリースタグ付きのバイナリはすべて自分を開発ビルドと見なし、自分自身の更新確認を静かにスキップしていました。

両方のコードパスが影響を受けました：

• 明示的な wpstaging update コマンド。これが、実行しても更新せずに「skipped」メッセージで打ち切られた理由です。
• 任意のコマンドで1日に1回走る自動のバックグラウンド確認。これが、アップグレードのバナーも一度も現れなかった理由です。

正味の影響は、v1.10.0 と v1.11.0 のインストールが自力で回復できないことです。修正は壊れたバイナリの外から来る必要があり、だからこそ復旧手順は上のインストーラーの一行であって wpstaging update ではありません。

私たちがしたこと

1. 修正を含む v1.11.1 をリリースしました。開発ビルドの判定は、まず先頭の v を取り除くようになり、v0.0.0-dev や dev のような本物の開発タグの場合にのみ更新パスをスキップします。
2. 重要な4つの形を網羅する回帰テストを追加しました：v1.11.1、1.11.1、v0.0.0-dev、dev。最初の2つは開発判定を通過しなければならず、後の2つは更新パスをスキップしなければなりません。順序が再び後退すれば、テストは大きく失敗します。
3. ライセンス API にサーバー側の通知チャネルの構築を始めました。これにより、将来まれに同様のロックアウトが起きた場合でも、更新パスそのものに依存せずに製品内メッセージを表示できます。

あなたがすべきこと

上の要点セクションから、あなたのプラットフォーム向けのインストーラーの一行を実行してください。これは次を行います：

• あなたの OS 向けに v1.11.1（以降）をダウンロードします。
• チェックサムを検証します。
• 既存の wpstaging バイナリをその場で置き換えます。
• あなたのサイト・ライセンス・キャッシュ・設定はそのまま残します。

終わったら、アップグレードが反映されたことを確認します：

wpstaging --version

v1.11.1 以上が表示されるはずです（リリースされたバイナリは先頭の v を出力します）。この時点から wpstaging update は期待どおりに動作し、毎日のバックグラウンド確認が今後のリリースを自動的に拾います。

この種のバグを防ぐ

このバグが特に厄介だったのは、壊れたコードパスが、本来あなたにアップグレードを知らせるのと同じものだったからです。ユーザー側の回避策は不可能で、復旧は私たちから来る必要がありました。同様のロックアウトが二度と静かに起こらないように、3つの層を導入しています：

• 回帰テスト — バージョンパーサーを、実際のリリースタグと開発タグの両方に対して実行し、取り除きと判定の順序が再びひそかに逆転されないようにします。
• リリース時のスモークチェック — ビルドされたバイナリに対して、実際のリリースタグで開発スキップのパスが取られないことを表明します。万一、開発判定が誤って有効なままリリースが出荷されようとすれば、バイナリがユーザーに届く前にビルドが失敗します。
• サーバー側の通知チャネル — ライセンス API に設けます。提供されれば、CLI は私たちの側から公開する短いメッセージを表示できるようになり、将来のあらゆるインシデントを、更新パスそのものを経由せずに伝えられます。

WP Staging CLI をご利用いただきありがとうございます。そして、この件で生じた手間をお詫びします。

これは AI が生成したコードの問題ではなく、ごく普通の人間によるエンジニアリングのミスでした。私たちはそれを見逃し、修正し、この特定の不具合が二度と静かに出荷されないよう、回帰テストとリリース時のチェックを追加しました。

質問や問題

インストーラーがうまく動かない、または再インストール後に予期しないものが見える場合は、ぜひご連絡ください：

• お問い合わせフォーム
• GitHub：WP Staging CLI リリースリポジトリで issue を開く