Come un piccolo bug del parser di versione ha rotto gli autoaggiornamenti di WP Staging CLI

Se stai usando WP Staging CLI v1.10.0 o v1.11.0, il comando integrato wpstaging update si rifiuterà di cercare aggiornamenti e stamperà «Update check skipped for development version». La CLI non può aggiornarsi da sé sul posto su queste due versioni. Questo post spiega cosa è andato storto, cosa abbiamo corretto e il comando una tantum che ti riporta a un’installazione sana.

In sintesi

Versioni interessate: solo v1.10.0 e v1.11.0. Per ripristinare, riesegui il nostro installer ufficiale. Rileva la tua installazione esistente, sostituisce il binario sul posto e lascia intatti i tuoi siti, la licenza e la configurazione.

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

Dopodiché sarai sulla v1.11.1 o successiva, e wpstaging update funziona di nuovo normalmente.

Cosa è successo

L’updater tratta qualsiasi cosa che non sembri una stringa semver pulita come una build di sviluppo e salta silenziosamente il controllo degli aggiornamenti. L’intenzione era ragionevole: quando compili la CLI in locale con go run o make build senza un flag di versione, altrimenti vedresti un confuso messaggio «Update vX.Y.Z available (current: vdev)» a ogni esecuzione di un comando.

Il bug: i nostri tag di rilascio vengono pubblicati come v1.10.0, v1.11.0 e così via, con una v iniziale. Il parser di versione, però, richiedeva un semplice 1.10.0. La v iniziale doveva essere rimossa per prima, ma il controllo della build di sviluppo veniva eseguito prima del passaggio di rimozione. Così ogni binario taggato come rilascio si vedeva come una build di sviluppo e saltava silenziosamente il proprio controllo degli aggiornamenti.

Entrambi i percorsi di codice erano interessati:

• Il comando esplicito wpstaging update, motivo per cui la sua esecuzione si interrompeva con il messaggio «skipped» invece di aggiornare.
• Il controllo automatico in background che viene eseguito una volta al giorno su qualsiasi comando, motivo per cui non è mai comparso nemmeno un banner di aggiornamento.

L’effetto netto è che le installazioni di v1.10.0 e v1.11.0 non possono recuperare da sole. La correzione deve venire dall’esterno del binario rotto, motivo per cui il passaggio di recupero è l’una-tantum dell’installer qui sopra e non wpstaging update.

Cosa abbiamo fatto

1. Rilasciata la v1.11.1 con la correzione. Il controllo della build di sviluppo ora rimuove prima la v iniziale e salta il percorso di aggiornamento solo su tag di sviluppo autentici come v0.0.0-dev e dev.
2. Aggiunti test di regressione che coprono le quattro forme che contano: v1.11.1, 1.11.1, v0.0.0-dev e dev. Le prime due devono superare il controllo di sviluppo; le ultime due devono saltare il percorso di aggiornamento. I test falliranno rumorosamente se l’ordine dovesse mai regredire di nuovo.
3. Iniziato a costruire un canale di notifica lato server nella nostra API delle licenze, così che, nel raro caso di un blocco simile in futuro, possiamo mostrare un messaggio nel prodotto senza dipendere dal percorso di aggiornamento stesso.

Cosa devi fare

Esegui l’una-tantum dell’installer per la tua piattaforma dalla sezione In sintesi qui sopra. Farà quanto segue:

• Scaricare la v1.11.1 (o successiva) per il tuo sistema operativo.
• Verificare il checksum.
• Sostituire il binario wpstaging esistente sul posto.
• Lasciare intatti i tuoi siti, la licenza, la cache e la configurazione.

Una volta terminato, conferma che l’aggiornamento è andato a buon fine:

wpstaging --version

Dovresti vedere v1.11.1 o superiore (i binari rilasciati stampano la v iniziale). Da questo momento, wpstaging update funziona come previsto e il controllo giornaliero in background recupererà automaticamente i rilasci futuri.

Prevenire questa classe di bug

Questo bug è stato particolarmente doloroso perché il percorso di codice rotto è lo stesso che normalmente ti direbbe di aggiornare. Una soluzione lato utente non era possibile; il recupero doveva venire da noi. Per assicurarci che un blocco simile non possa ripetersi silenziosamente, stiamo mettendo in atto tre livelli:

• Test di regressione che mettono alla prova il parser di versione sia contro veri tag di rilascio sia contro tag di sviluppo, così che l’ordine tra rimozione e controllo non possa essere invertito di nuovo di nascosto.
• Un controllo smoke al momento del rilascio sul binario compilato che afferma che il percorso di salto sviluppo non viene preso per il tag di rilascio effettivo. Se un rilascio dovesse mai essere spedito con il controllo di sviluppo erroneamente attivo, la build fallirà prima che il binario raggiunga gli utenti.
• Un canale di notifica lato server nell’API delle licenze. Una volta consegnato, la CLI potrà mostrare brevi messaggi che pubblichiamo dalla nostra parte, così che qualsiasi incidente futuro possa essere comunicato senza passare dal percorso di aggiornamento stesso.

Grazie per usare WP Staging CLI, e ci scusiamo per l’attrito che questo caso ha causato.

Questo è stato un comune errore umano di ingegneria, non un problema di codice generato dall’IA. Lo abbiamo mancato, corretto e abbiamo aggiunto controlli di regressione e al momento del rilascio affinché proprio questo guasto non possa essere spedito di nuovo in silenzio.

Domande o problemi

Se l’installer non funziona per te, o vedi qualcosa di inaspettato dopo la reinstallazione, contattaci:

• Modulo di contatto
• GitHub: apri una issue sul repository dei rilasci di WP Staging CLI