Non ha molta importanza se si tratta di una libreria o di un’applicazione più grande. Uno schema di versionamento semantico funziona perfettamente per un’applicazione di grandi dimensioni. Può anche essere utilizzato per una raccolta di applicazioni raggruppate in una piattaforma, ma qui diventa piuttosto difficile da gestire.
La domanda principale è se si segue il percorso della deprecazione supportata in una release e solo la rimozione nella successiva release principale. Avere funzionalità deprecate, ma supportate, può richiedere un notevole sforzo. Quando si apportano modifiche al proprio modello di dati persistente, la deprecazione può spesso diventare impossibile. Se ciò accade, non è nemmeno possibile effettuare una release minore con funzionalità deprecate e si salta immediatamente alla successiva release principale. Questa è la parte in cui le applicazioni di grandi dimensioni di solito hanno problemi. Si passa da 3.0.0 a 3.0.1 a 4.0.0 perché non è possibile fornire retrocompatibilità. Se si hanno spesso modifiche che interrompono la compatibilità, attenersi a semver aggiunge poco valore.
Detto questo, preferisco di gran lunga quella costruzione perché comunica più chiaramente agli sviluppatori che ci saranno modifiche che interrompono la compatibilità. Lo schema YYYY.N non mi dice nulla come sviluppatore e nulla come amministratore.
Quindi la domanda è, cosa vuoi comunicare con la versione? Se vuoi fare 6 release di funzionalità (che potrebbero o meno interrompere la compatibilità), e ogni 6a release sarà supportata più a lungo con patch; e non vuoi versionare le release di patch. Allora X.Y è uno schema adatto dove Y=0 è quello supportato più a lungo. X sarebbe solo un numero. Il problema è quando X è l’anno, allora Y è rapidamente associato a un mese. Quindi le nuove release supportate più a lungo verranno rilasciate a gennaio? Devo sempre cercare quale versione di Ubuntu è una LTS, il che mi infastidisce.
Quindi, cosa succederebbe se Discourse continuasse semplicemente con la versione principale attuale. La prossima versione supportata più a lungo si chiama 4.0; e poi otteniamo 4.1 a 4.5 come release di funzionalità; seguita da 5.0 che è la più recente supportata più a lungo.
Quindi non avrai nemmeno quel momento imbarazzante in cui una release viene ritardata a causa di un problema importante.
Potresti facoltativamente aggiungere un numero di “patch” se hai intenzione di rilasciare esplicitamente patch (invece di avere release di patch continue). “Ma allora avrai x.y.z che è semver”. Beh, no, sembra semver, ma non lo è. Ogni nuova release “minore” può interrompere la compatibilità. Quindi suggerisco di attenersi semplicemente a X.Y come schema di versionamento con Y=0 → LTS.
A parte la stringa di versione. Mi piace il nuovo piano di rilascio.