Semantic Versioning consente 4 componenti in numeri di versione?

Tutti gli esempi di versioning semantico che ho visto mostrano 3 componenti in uso. Non più di 2 caratteri punto. A $DAYJOB, usiamo 4 componenti nei nostri numeri di rilascio:

5.0.1.2

La versione semantica lo consente?

E come domanda secondaria di livello superiore e più discutibile, importa davvero? Ho iniziato a pensare che potrebbe essere una buona idea imporre il controllo delle versioni semantico, ma alla fine entità come PCI lo sovrascrivono.

Avrei dovuto chiarire il mio commento PCI. Il problema è che gli audit e la loro influenza sui costi quando cambiano i componenti principali e secondari, non necessariamente una vera nuova funzionalità. Ad esempio, se viene introdotta una funzione correlata ai pagamenti, aumentiamo il numero minore per PCI. Ma se aggiungiamo una nuova funzionalità correlata a qualcosa nella GUI, non lo fa. Cambia solo la patch. Quindi, in questo caso, non abbiamo davvero voce in capitolo come sviluppatori poiché qualcun altro prende quelle decisioni.

versioning semantic-versioning pci

— void.pointer
fonte

Il versioning semantico è una linea guida. Dove PCI afferma qualcosa su come le cose devono essere versionate?

Avrei dovuto chiarire il mio commento PCI. Il problema è che gli audit e la loro influenza sui costi quando cambiano le componenti principali e secondarie, non necessariamente una vera nuova funzionalità. Ad esempio, se viene introdotta una funzionalità correlata ai pagamenti, aumentiamo il numero minore per PCI. Ma se aggiungiamo una nuova funzionalità correlata a qualcosa nella GUI, non lo fa. Cambia solo la patch. Quindi, in questo caso, non abbiamo davvero voce in capitolo come sviluppatori poiché qualcun altro prende quelle decisioni.

— void.pointer

@ void.pointer puoi fare un esempio del perché stai usando il quarto componente allora? Lo stai usando essenzialmente per aggirare le strutture di costo e contabilità interne - lasciando che il tuo team tenga traccia delle nuove funzionalità senza superare i numeri di patch?

— enderland,

@enderland Sì, fondamentalmente. MAJOR(PCI).MINOR(PCI).FEATURE.HOTFIX+BUILD. Fondamentalmente ci è permesso cambiare il 3o e il 4o componente senza coinvolgere PCI (e successivamente i signori PCI dell'azienda). Per me sembra che questo sia un po 'inventato, non sono sicuro che siano giustificati nel modo in cui gestiscono il numero di versione, ma non conosco abbastanza il PCI e il processo di audit per dire diversamente.

— void.pointer

Utilizziamo anche 4 gruppi e non 3. Perché? Perché C ++. Il C ++ ha retrocompatibilità binaria e retrocompatibilità dei sorgenti : il primo implica il secondo, ma la relazione non è simmetrica. Pertanto, utilizziamo il 4 ° gruppo per la compatibilità binaria (è possibile eseguire l'hot-patch del sistema) e il 3 ° per la compatibilità dei sorgenti (è necessario ricompilare, ma non è necessario modificare il proprio codice). E sai cosa, funziona per noi!

— Matthieu M.

Risposte:

Sembra che tu stia scavalcando le convenzioni normali solo per evitare le spese generali di processo / audit. Questo ... mi sembra preoccupato.

Quello che stai facendo è effettivamente creare un numero di versione aggiuntivo (la tua cifra PCI minore) un po 'intenzionalmente al fine di spostare i tuoi numeri di funzione / versione minore indietro di un posto, per non innescare più i tuoi criteri di controllo interno.

Comunque, arrivando alla tua domanda sul versioning semantico, le specifiche per il Semantic Versioning indicano :

Dato un numero di versione MAJOR.MINOR.PATCH, incrementare:

Versione MAJOR quando si apportano modifiche API incompatibili,

Versione MINORE quando si aggiunge funzionalità in modo compatibile con le versioni precedenti e

Versione PATCH quando si apportano correzioni di bug compatibili con le versioni precedenti.

Ulteriori etichette per i metadati pre-release e build sono disponibili come estensioni nel formato MAJOR.MINOR.PATCH .

Enfasi mia.

Quindi la domanda è: stai usando il quarto carattere per i metadati pre-release / build? O è fondamentalmente un'altra indicazione di versione che stai rilasciando?

Se "sì", le specifiche di versione semantica lo consentono. Se "no", tecnicamente non stai seguendo il controllo delle versioni semantico.

E come domanda secondaria di livello superiore e più discutibile, importa davvero?

Indipendentemente dal fatto che tu voglia seguirlo rigidamente o meno, è una decisione che tu e il tuo team dovete prendere. Lo scopo del versioning semantico è di aiutare con la compatibilità API:

Le correzioni di bug che non influiscono sull'API aumentano la versione della patch, le aggiunte / modifiche all'API compatibili all'indietro aumentano la versione secondaria e le modifiche all'API incompatibili all'indietro aumentano la versione principale.

Chiamo questo sistema "Semantic Versioning". In base a questo schema, i numeri di versione e il modo in cui cambiano trasmettono significato sul codice sottostante e su ciò che è stato modificato da una versione all'altra.

È un sistema che aiuta a renderlo più chiaro quando il controllo delle versioni influisce sugli utenti a valle dell'API.

Fintanto che la tua API è altrettanto chiara, non è un grosso problema il modo in cui scegli. Il versioning semantico sembra essere semplice, ad esempio se sto usando 3.4.2 e devo aggiornare a 3.4.10 So che posso farlo senza interrompere nulla. Se la nuova versione è 3.5.1 so che è retrocompatibile. E so che la versione 4.0.1 sarebbe un cambiamento decisivo.

Fa tutto parte del significato dei numeri di versione.

@enderland Sì, fondamentalmente. MAGGIORE (PCI) .MINOR (PCI) .FEATURE.HOTFIX + build. Fondamentalmente ci è permesso cambiare il 3o e il 4o componente senza coinvolgere PCI (e successivamente i signori PCI dell'azienda). Per me sembra che questo sia un po 'inventato, non sono sicuro che siano giustificati nel modo in cui gestiscono il numero di versione, ma non conosco abbastanza il PCI e il processo di audit per dire diversamente.

Ok, va bene. Hai un sistema che funziona per te e soddisfa le tue esigenze. Questo è il punto del controllo delle versioni.

Se la tua API è privata (solo internamente) non importa in che modo la tua versione fintanto che ha senso per te e per tutti coloro che la utilizzano. Dove conta il controllo delle versioni in un formato standard quando hai molti altri consumatori della tua API che devono sapere "cosa significa questa versione?"

Avere un sistema di versioning arbitrario confonderà le persone che sono abituate ad altri sistemi, come il versioning semantico. Ma se nessuno usa davvero il tuo sistema di controllo delle versioni tranne le persone che lo creano, non importa.

— enderland
fonte

Per quanto riguarda la tua modifica in alto: fammi giocare qui all'avvocato del diavolo. Gli audit PCI costano denaro all'azienda e non tutte le funzionalità implementate li riguardano. Quindi perché sostenere costi e altre spese generali solo sui principi? In che modo è così preoccupante? Mi rendo conto che il metodo per determinare gli audit è probabilmente imperfetto, ma la separazione delle preoccupazioni sembra ragionevole. Le cose non legate in remoto all'elaborazione delle carte sono irrilevanti per PCI.

— void.pointer

@ void.pointer Non sono in grado di giudicare perché / come sono determinati i tuoi audit. Ma qualcuno ha deciso di voler controllare in base a criteri specifici. Ignorare intenzionalmente i criteri di audit sembra riguardare (indipendentemente dalla quantità di denaro risparmiata facendo ciò).

— Enderland,

@ void.pointer, enderland ha ragione. Se un terrorista minaccia di uccidere la tua famiglia se le tue versioni non sono composte interamente da lettere alfabetiche, il vero problema è il terrorista. Sentiti libero di non seguire il versioning semantico per aggirare il problema (in effetti, in questo caso lo consiglio vivamente), ma è davvero questo: una soluzione alternativa resa necessaria da un problema diverso.

— Paul Draper,

@PaulDraper Quando semver è diventato il One True Way alla versione?

— Andy,

@Andy, non l'ha fatto. L'OP ha chiesto di SemVer. IDK perché, ma è quello che ha fatto.

— Paul Draper,

Nella versione corrente di Semantic Versioning, che è 2.0.0 , n. Esiste un requisito che definisce la versione come forma XYZ in cui X, Y e Z sono numeri interi non negativi che non contengono 0 iniziali:

Un numero di versione normale DEVE assumere la forma XYZ in cui X, Y e Z sono numeri interi non negativi e NON DEVE contenere zero iniziali. X è la versione principale, Y è la versione secondaria e Z è la versione della patch. Ogni elemento DEVE aumentare numericamente. Ad esempio: 1.9.0 -> 1.10.0 -> 1.11.0.

Tuttavia, la possibilità di aggiungere metadati è consentita per:

I metadati di compilazione POSSONO essere indicati aggiungendo un segno più e una serie di identificatori separati da punti immediatamente dopo la patch o la versione preliminare. Gli identificatori DEVONO comprendere solo caratteri alfanumerici ASCII e trattino [0-9A-Za-z-]. Gli identificatori NON DEVONO essere vuoti. Costruire metadati DOVREBBE essere ignorato quando si determina la precedenza della versione. Pertanto, due versioni che differiscono solo nei metadati di build hanno la stessa precedenza. Esempi: 1.0.0-alpha + 001, 1.0.0 + 20130313144700, 1.0.0-beta + exp.sha.5114f85.

Qualcosa di importante da notare, tuttavia, è che Semantic Versioning è specificamente per il software che dichiara un'API pubblica:

Il software che utilizza la versione semantica DEVE dichiarare un'API pubblica. Questa API potrebbe essere dichiarata nel codice stesso o esistere rigorosamente nella documentazione. Comunque sia, dovrebbe essere preciso e completo.

Ciò tende a supportare lo sviluppo di librerie o servizi e non a livello di applicazione.

La cosa importante da considerare è il significato dei numeri di versione, sia per uso interno che esterno. Le versioni sono solo identificatori che ti consentono di parlare delle differenze nel software in due diversi momenti nel tempo. Il controllo delle versioni semantico è un metodo per aggirare le regole, quindi se sai che un'applicazione utilizza il controllo delle versioni semantico, puoi determinare più facilmente il livello di sforzo richiesto per aggiornare i tuoi pacchetti. Seguire uno standard comune può essere buono, ma se non è possibile per qualsiasi motivo, dovrebbe essere sufficiente documentare le regole per gli utenti.

— Thomas Owens
fonte

+1 per la nota API pubblica. Non disponiamo di un'API pubblica ma abbiamo la possibilità di interrompere la compatibilità con le versioni precedenti in altri aspetti, come i dati. È possibile che forniamo una build che viene installata su versioni precedenti ma i dati non cambiano e non siamo più in grado di leggere tali dati (di solito supportiamo i vecchi formati)

— void.pointer