Versioni di Checkmk

Sul ramo di sviluppo (nel controllo di versione di Git questo viene chiamato "master") viene sviluppato il futuro di Checkmk. Affinché gli sviluppatori, gli utenti e le altre parti interessate possano avere in qualsiasi momento un'idea dello stato attuale del software, ogni giorno tra le 0:00 e le 6:00 ora dell'Europa centrale viene creato un pacchetto di installazioni per tutte le versioni di distribuzione Linux supportate. Questi pacchetti sono chiamati build giornaliere, istantanee Git o versioni developer e rappresentano lo stato esatto dello sviluppo del software all'inizio di ogni giorno.

Naturalmente, le build giornaliere conterranno spesso alcuni bug, poiché contengono un'istantanea più o meno "casuale" dello stato attuale del software. A differenza delle versioni Innovation e Stable, le build giornaliere non generano alcun nuovo ramo di sviluppo e quindi non possono essere patchate da noi. L'unico modo per correggere un errore in una build giornaliera è quello di sostituirla con una build giornaliera più recente, che potrebbe avere i suoi problemi. Per questo motivo, una build giornaliera non dovrebbe mai essere utilizzata in un ambiente di produzione.

Tuttavia, le build giornaliere sono molto utili se l'utente desidera provare nuove funzionalità in tempo reale, soprattutto se è stato lui stesso a commissionarci lo sviluppo della funzionalità!

Il nostro supporto sarà lieto di aiutarti in caso di difficoltà con le build giornaliere, ma con le seguenti restrizioni:

Le versioni Innovation sono una caratteristica speciale delle edizioni commerciali e ti danno la possibilità di utilizzare nuove e interessanti funzionalità del software molto prima che venga rilasciata la versione stabile successiva. Rappresentano un compromesso tra stabilità e nuove funzionalità. Tuttavia, le versioni Innovation sono opzionali e non vengono fornite in preparazione di ogni versione stabile.

Di regola la prima versione Innovation è disponibile circa mezzo anno dopo l'ultima versione stabile. Nei 1-2 mesi successivi verranno prodotte 3-4 versioni, ognuna identificata in sequenza da un numero i (ad es, 2.0.0i2Analogamente alle versioni stabili, anche queste verranno mantenute attivamente, ma solo per un periodo limitato di circa 1-2 mesi, seguito da un periodo analogo di manutenzione passiva. Le patch delle versioni i possono essere riconosciute da un suffisso p, ad es, 2.0.0i2p1.

Il rilascio di una nuova versione stabile (es. 2.3.0), inizia con una fase beta. Per correggere tutti gli errori e rendere il software pronto per la produzione, verrà separato un ramo stabile aggiuntivo contenente solo le correzioni degli errori. Lo sviluppo delle funzionalità per le versioni future continua in parallelo sul ramo principale.

Sul ramo stabile verrà pubblicata una serie di versioni beta, identificate da un b minuscolo nel loro nome (es, 2.3.0b1, 2.3.0b2Ciò avviene ogni due settimane circa, a patto che non vengano identificati errori gravi.

Dopo la fase beta, viene rilasciata una versione stabile, detta anche major release, ad esempio, 2.3.0Ora che molti utenti stanno provando la nuova versione, verranno identificati altri problemi che non erano stati notati durante la fase beta. Questi verranno corretti da una serie di versioni patch, a volte chiamate anche patch release (2.3.0p1, 2.3.0p2Gli intervalli di tempo tra queste versioni patch saranno inizialmente piuttosto brevi (circa una settimana), mentre in seguito saranno molto più lunghi (alcuni mesi).

Oltre al master, vengono pubblicate anche build giornaliere sul ramo stabile, che forniscono correzioni di bug immediate. Queste riportano il nome del ramo e la data, ad es, 2.3.0-2024.03.30.

Puoi utilizzare queste versioni in produzione, a patto che tu osservi quanto segue:

La manutenzione attiva di questa versione stabile viene effettuata con versioni patch. La durata dipende dal momento in cui viene rilasciata la versione successiva, che diventa così la nuova versione stabile. La regola della versione 1.6.0 è: la manutenzione attiva termina per una versione 6 mesi dopo il rilascio della nuova versione. Poiché per la versione stabile la versione successiva non è ancora stata rilasciata, la data di rilascio prevista serve a determinare il ciclo di vita del prodotto.

Ciò significa che per 6 mesi vengono mantenute due versioni in parallelo con le versioni patch: la versione stabile e la versione precedente(oldstable). Una panoramica del ciclo di vita del prodotto si trova alla fine di questo articolo.

Dopo la fine della manutenzione attiva, il ramo stabile passa alla fase di manutenzione passiva, che generalmente dura un altro anno.

In questo periodo, in genere, risolviamo gli errori solo su richiesta dei clienti che utilizzano i ticket di assistenza tramite un contratto di assistenza.

Le correzioni di bug durante la fase di manutenzione passiva generano ulteriori versioni patch, che ovviamente sono utili anche agli utenti che non hanno un contratto di assistenza.

Per sapere se la tua versione è ancora in fase di manutenzione e quando ha raggiunto o raggiungerà la sua fine vita, puoi consultare la seguente tabella:

Per le versioni più vecchie consigliamo vivamente di effettuare l'aggiornamento.