Como um pequeno bug do analisador de versão quebrou as autoatualizações do WP Staging CLI

Se você está executando o WP Staging CLI v1.10.0 ou v1.11.0, o comando integrado wpstaging update se recusará a verificar atualizações e exibirá «Update check skipped for development version». A CLI não consegue se atualizar no local nessas duas versões. Este post explica o que deu errado, o que corrigimos e o comando único que traz você de volta a uma instalação saudável.

Resumo

Versões afetadas: apenas v1.10.0 e v1.11.0. Para se recuperar, execute novamente o nosso instalador oficial. Ele detecta a sua instalação existente, substitui o binário no local e deixa os seus sites, a sua licença e a sua configuração intactos.

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

Depois disso, você estará na v1.11.1 ou posterior, e o wpstaging update volta a funcionar normalmente.

O que aconteceu

O atualizador trata qualquer coisa que não pareça uma string semver limpa como uma compilação de desenvolvimento e pula silenciosamente a verificação de atualizações. A intenção era razoável: quando você compila a CLI localmente com go run ou make build sem uma flag de versão, você veria, caso contrário, uma confusa mensagem «Update vX.Y.Z available (current: vdev)» toda vez que executasse um comando.

O bug: as nossas tags de lançamento são publicadas como v1.10.0, v1.11.0 e assim por diante, com um v inicial. O analisador de versão, no entanto, exigia um 1.10.0 simples. O v inicial deveria ser removido primeiro, mas a verificação de compilação de desenvolvimento era executada antes do passo de remoção. Assim, cada binário marcado como lançamento se via como uma compilação de desenvolvimento e pulava silenciosamente a sua própria verificação de atualização.

Ambos os caminhos de código foram afetados:

• O comando explícito wpstaging update, motivo pelo qual executá-lo interrompia com a mensagem «skipped» em vez de atualizar.
• A verificação automática em segundo plano que roda uma vez por dia em qualquer comando, motivo pelo qual também nunca apareceu um banner de atualização.

O efeito líquido é que as instalações da v1.10.0 e v1.11.0 não conseguem se recuperar sozinhas. A correção tem que vir de fora do binário quebrado, motivo pelo qual o passo de recuperação é o comando único do instalador acima e não o wpstaging update.

O que fizemos

1. Lançamos a v1.11.1 com a correção. A verificação de compilação de desenvolvimento agora remove primeiro o v inicial, e só pula o caminho de atualização em tags de desenvolvimento genuínas como v0.0.0-dev e dev.
2. Adicionamos testes de regressão que cobrem as quatro formas que importam: v1.11.1, 1.11.1, v0.0.0-dev e dev. As duas primeiras devem passar na verificação de desenvolvimento; as duas últimas devem pular o caminho de atualização. Os testes falharão ruidosamente se a ordem regredir alguma vez.
3. Começamos a construir um canal de notificação do lado do servidor na nossa API de licenças, para que, no raro caso de um bloqueio semelhante no futuro, possamos exibir uma mensagem dentro do produto sem depender do próprio caminho de atualização.

O que você precisa fazer

Execute o comando único do instalador para a sua plataforma a partir da seção Resumo acima. Ele vai:

• Baixar a v1.11.1 (ou posterior) para o seu sistema operacional.
• Verificar a soma de verificação.
• Substituir o binário wpstaging existente no local.
• Deixar os seus sites, a sua licença, o seu cache e a sua configuração intactos.

Quando terminar, confirme que a atualização foi aplicada:

wpstaging --version

Você deve ver v1.11.1 ou superior (os binários lançados exibem o v inicial). A partir desse ponto, o wpstaging update funciona como esperado, e a verificação diária em segundo plano pegará os lançamentos futuros automaticamente.

Prevenindo essa classe de bug

Este bug foi particularmente doloroso porque o caminho de código quebrado é o mesmo que normalmente diria a você para atualizar. Uma solução do lado do usuário não era possível; a recuperação tinha que vir de nós. Para garantir que um bloqueio semelhante não possa ocorrer novamente em silêncio, estamos colocando três camadas em prática:

• Testes de regressão que exercitam o analisador de versão tanto contra tags de lançamento reais quanto contra tags de desenvolvimento, para que a ordem entre remover e verificar não possa ser silenciosamente invertida de novo.
• Uma verificação de fumaça no momento do lançamento sobre o binário compilado que afirma que o caminho de pulo de desenvolvimento não é tomado para a tag de lançamento real. Se um lançamento alguma vez for enviado com a verificação de desenvolvimento ativa por engano, a compilação falhará antes de o binário chegar aos usuários.
• Um canal de notificação do lado do servidor na API de licenças. Uma vez entregue, a CLI poderá exibir mensagens curtas que publicamos do nosso lado, para que qualquer incidente futuro possa ser comunicado sem passar pelo próprio caminho de atualização.

Obrigado por usar o WP Staging CLI, e desculpe pelo atrito que este caso causou.

Este foi um simples erro humano de engenharia, não um problema de código gerado por IA. Nós o deixamos passar, corrigimos e adicionamos verificações de regressão e do momento do lançamento para que essa falha específica não possa ser enviada novamente em silêncio.

Dúvidas ou problemas

Se o instalador não funcionar para você, ou se você vir algo inesperado após reinstalar, entre em contato:

• Formulário de contato
• GitHub: abra uma issue no repositório de lançamentos do WP Staging CLI