guides

I nomi attorno al software di preversione suggeriscono un'unica scala, e quasi tutte le spiegazioni mettono la nightly sul suo gradino più basso. L'immagine è sbagliata, ed è per questo che sorprende quando una nightly che piaceva semplicemente sparisce.

Una nightly build è un'istantanea di ciò che si trovava sul ramo principale quando l'orologio ha suonato. È prodotta automaticamente, per calendario e non per decisione, e nessuno l'ha giudicata pronta per qualcosa.

Tappa contro canale

La distinzione che conta è tra una tappa e un canale. Una alpha, una beta o una release candidate è una tappa: esiste perché si sta preparando una pubblicazione precisa, e finisce quando quella esce. Un canale nightly non ha destinazione. Ha prodotto una build stanotte, ne produrrà una stasera, e continuerà a produrne molto dopo che la versione attesa sarà uscita e dimenticata.

Per questo una nightly non ha un numero di versione nel senso ordinario, e per questo fissarsi a una significa fissarsi a una data e non a una promessa.

Che cosa rendono visibile i canali di Rust

Rust rende l'assetto insolitamente leggibile, e vale la pena leggerlo alla lettera. La sua documentazione descrive una nuova versione nightly prodotta ogni notte, creata automaticamente dall'infrastruttura di rilascio. Ogni sei settimane il ramo beta si stacca dallo stesso ramo principale, e sei settimane dopo da beta viene prodotta una versione stabile.

• Tappa (alpha, beta, rc): esiste per preparare una pubblicazione precisa e finisce quando esce
• Canale (nightly): produce per calendario, non ha destinazione, non finisce mai
• Conseguenza: una nightly identifica una data o un commit, non una versione con una promessa

Lo stesso commit viaggia dunque: atterra in nightly il giorno del merge, raggiunge beta al successivo confine di sei settimane e diventa stabile sei settimane più tardi. Il canale nightly è la porta d'ingresso, non un'edizione di qualità inferiore del prodotto finito.

Rust lo usa anche per qualcosa che un numero di versione non può esprimere. Le funzionalità in sviluppo stanno dietro feature flag disponibili solo su nightly; su beta o stable non si possono usare affatto. Il canale è quindi un confine di capacità tanto quanto di freschezza, ed è per questo che alcuni progetti richiedono davvero nightly invece di limitarsi a trarne vantaggio.

Che cosa ne segue in pratica

Le conseguenze pratiche discendono dal calendario. Una nightly può essere rotta in modi in cui nessuna versione pubblicata lo sarebbe, perché nulla l'ha filtrata. Due persone che eseguono "la nightly" in giorni diversi eseguono software diverso, quindi una segnalazione su una non significa nulla senza la data o il commit. E una correzione vista in una nightly può metterci settimane ad arrivare al canale stabile, o essere annullata prima.

Niente di tutto questo rende cattive le nightly. Le rende uno strumento diverso: quello giusto per riprodurre un bug sul ramo principale attuale, verificare se qualcosa è già corretto, o usare una funzionalità non ancora pubblicata. Quello sbagliato per tutto ciò che devi tenere in funzione.

Se volevi il contrario

Se quello che vuoi davvero è stabilità su un orizzonte lungo, la via LTS è l'estremo opposto dello stesso asse, e il versionamento semantico spiega che cosa promettono i numeri dal lato stabile.

Il riassunto onesto è che nightly non è un'etichetta di qualità. È un'affermazione su quando il codice è stato preso, e tutto il resto, compreso se funziona, resta volutamente non detto.