Il blog di Greg Kroah-Hartman, maintainer delle versioni stabili del Kernel Linux, non viene aggiornato spessissimo, ma ogni volta che succede, e la scorsa settimana è successo due volte, è sempre un gran piacere leggere tutte le cose interessanti che chi vive da vicino il Pinguino vuole condividere.

Nell’articolo intitolato Linux kernel version numbers, ad esempio, vengono chiariti alcuni aspetti di gestione delle versioni su cui normalmente non ci si pone il problema. Anzitutto non esiste più il concetto di “Old”, e questa cosa è valida più o meno da… 20 anni! È terminata infatti con il Kernel 2.6.0, il 17 dicembre del 2003 e, da allora, ogni versione del Kernel Linux è considerata Stable.

Nella pratica questo si traduce in una semplice regola: per gli utenti nessuna nuova release dovrebbe impattare alcun codice o workflow esistente.

In questo modo, e si capisce in fretta il perché, non c’è ragione per un utente di rimanere su una release “vecchia”, e non ci sono rischi.

Le versioni sono sequenziali e, sebbene abbiamo imparato negli anni a capire che la Major Release venga decisa un po’ a caso in base alle sensazioni di Linus Torvalds, numeri alti significano versioni più recenti. Ciascuna release Stable viene pubblicata con una cadenza costante, con un ciclo di sviluppo che dura in media 10 settimane, e la struttura è ben riassunta nello schema pubblicato:

La struttura è Major.Minor.Stable: Major, come detto, viene incrementato “a sensazione”, cioè quando il Minor diventa troppo grande da gestire, insieme questi due elementi rappresentano il “Kernel Branch“, mentre la componente Stable rappresenta il numero di release e se questa è ancora in sviluppo, quindi “Release Candidate“.

È interessante notare poi l’aspetto relativo alla produzione delle release, poiché tutto parte dalla mainline di Torvalds, e ciascun nuovo ramo Stable può esistere contemporaneamente agli altri, purché sia subordinato al mainline, così da evitare regressioni nella disponibilità delle correzioni e garantire che passando a una versione successiva non si perdano i bugfix già introdotti.

A tutto questo si aggiungono le release Long Term Support che, a differenza delle release transitorie (ossia quelle che nello schema sono nella colonna di destra verdi) che durano qualche settimana, sono manutenute per due anni.

Ed a proposito di questo, un ultimo aspetto relativo alla sicurezza che tutte le aziende dovrebbero tener presente: non è detto che una release precedente all’attuale sia meno aggiornata, perché ovviamente dipenderà dai backport che eventualmente le sono stati applicati in quanto LTS.

Considerato che questo articolo è solo il primo di una serie, e che già altri ne sono stati pubblicati (come Tracking kernel commits across branches) il consiglio è quello di sottoscrivere il feed di questo interessante blog!