guides

Una release candidate non è una beta con un nome più serio. È un'affermazione precisa: questa è la build che intendiamo pubblicare e, a meno che qualcuno non trovi un problema bloccante, diventa la versione finale senza altre modifiche. In alcuni progetti la RC e la versione pubblicata sono gli stessi byte con un'etichetta diversa.

Che cosa afferma davvero l'etichetta

Quell'affermazione è ciò che rende utile l'etichetta, ed è anche ciò che la rende facile da fraintendere. Una RC non vuol dire che il software sia privo di difetti. Vuol dire che il team ha smesso di aggiungere cose e non conosce più motivi per non pubblicare.

Ne discendono due conseguenze. La prima è che una RC è l'ultimo momento in cui segnalare un problema cambia ancora l'esito, ed è esattamente per questo che i produttori le pubblicano. La seconda è che un numero di RC che sale è un segnale in sé: se vedi rc.4, tre candidate precedenti sono state respinte, e la pubblicazione è meno assestata di quanto la parola suggerisca.

Vale anche la pena sapere che il termine è una convenzione e non uno standard. Nulla impone che cosa un produttore intenda con esso. Alcuni pubblicano una RC che diventa disponibile in generale senza modifiche, altri continuano a correggere dopo la comparsa dell'etichetta. La parola da sola non garantisce nulla, e solo le note di rilascio del progetto lo chiariscono.

Alpha, beta, rc: una scala di completezza

La scala che porta fino a lei è una scala di completezza, non di qualità, ed è questa distinzione che si capisce male.

• alpha - incompleta, le interfacce possono ancora cambiare, le rotture sono attese
• beta - completa nelle funzionalità, i difetti si stanno ancora trovando
• rc - nulla di noto sta bloccando, esce così com'è se non emerge niente di nuovo

Una alpha è incompleta. Mancano funzionalità, le interfacce cambieranno ancora, e le rotture sono attese più che segnalate. Una beta è completa nelle funzionalità: c'è tutto quello che sarà nella versione pubblicata, e resta da scoprire che cosa non va. Una release candidate aggiunge un'affermazione in più, che nulla di noto stia bloccando. Le tre fasi differiscono per quello che è finito, non per la cura con cui è stato scritto:

Come SemVer ordina una preversione

Il versionamento semantico codifica esattamente quest'ordine, e leggerlo alla lettera risponde alla maggior parte delle domande. Gli identificatori di preversione si agganciano alla versione con un trattino, e una preversione si ordina sempre prima della versione a cui appartiene: 1.2.0-rc.1 viene quindi prima di 1.2.0.

Dentro la parte di preversione, gli identificatori separati da punti si confrontano uno a uno. Quelli numerici si confrontano numericamente e stanno sotto quelli alfanumerici, ed è per questo che 1.2.0-alpha.1 precede 1.2.0-alpha.beta, e che rc.2 segue correttamente rc.10 solo se ci si ricorda che sono numeri. Il nostro articolo sul versionamento semantico copre il resto della grammatica.

Il tuo gestore di pacchetti non ne prenderà una per sbaglio

Ecco la parte pratica che sorprende, ed è una protezione più che un difetto. Un normale intervallo di versioni non corrisponde a una preversione. Se il tuo manifesto chiede ^1.2.0, non prenderà 1.3.0-rc.1 anche se il numero è più alto. Devi nominare la preversione esplicitamente, o usare un intervallo che ne contenga già una con gli stessi major, minor e patch.

Quella regola è ciò che impedisce a una RC di finire nella tua build per sbaglio, ed è anche ciò che rende il provarne una un atto deliberato: la fissi, apposta, in un ambiente in cui puoi permetterti la risposta.

Che cosa farne

Da cui il consiglio onesto. Fai girare le release candidate in integrazione continua e su una macchina di staging, non in produzione, a meno che la RC non contenga una correzione che ti serve in modo specifico e tu ne abbia accettato il prezzo. Se ne fai girare una, segnala quello che trovi, perché è tutto il senso dell'esercizio e la finestra si chiude con la pubblicazione. E leggi il changelog fra l'ultima RC e la build finale: se è vuoto, la candidata che hai provato è la versione che riceverai, ed è la notizia migliore che questo processo possa dare. Per sistemi di lunga durata in cui preferisci non stare vicino al bordo, la via LTS esiste proprio per evitare questa decisione.