La versione semantica consente 4 componenti nei numeri di versione?

Sembra che tu stia bypassando le normali convenzioni solo per evitare il sovraccarico del processo / i controlli. Questo ... mi colpisce per quanto riguarda.

Ciò che stai facendo è in realtà un numero di versione extra (la tua cifra PCI minore) alquanto intenzionalmente per spostare la tua funzione / numeri di versione minori indietro un luogo, per non attivare più il tuo audit interno criteri.

Ad ogni modo, arrivando alla tua domanda sulla versione semantica, la specifica per la versione semantica afferma:

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards-compatible manner, and
• PATCH version when you make backwards-compatible bug fixes.
• Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Enfasi sulla mia.

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

Se "si", le specifiche della versione semantica lo consentono. Se "no", tecnicamente non stai seguendo il versioning semantico.

And as a higher-level and more arguable side question, does it really even matter?

Se lo vuoi seguire rigidamente o no è una decisione che tu e il tuo team dovete prendere. Lo scopo del versioning semantico è quello di aiutare con la compatibilità API:

Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

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

Se la tua API è altrettanto chiara, non è un grosso problema come scegli tu. Il versioning semantico sembra essere semplice, per esempio se sto usando 3.4.2 e devo aggiornare a 3.4.10 So che posso farlo senza rompere nulla. Se la nuova versione è 3.5.1, so che è retrocompatibile. E so che la versione 4.0.1 sarebbe un cambiamento radicale.

Tutto fa parte di ciò che significano i numeri di versione.

@enderland Yes basically. MAJOR(PCI).MINOR(PCI).FEATURE.HOTFIX+BUILD. We're basically only allowed to change the 3rd and 4th component without getting PCI (and subsequently the PCI overlords at the company) involved. To me it feels like this is a bit contrived, I am not sure they are justified in the way they manage the version number, but I do not know enough about PCI and audit process to say otherwise.

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

Se la tua API è privata (solo rivolta verso l'interno), non importa come la tua versione purché abbia senso per te e per tutti quelli che la utilizzano. Dove il versioning in un formato standard è importante quando ci sono molti altri utenti della tua API che devono sapere "cosa significa questa versione?"

Avere un sistema di controllo delle versioni arbitrario confonderà le persone che sono abituate ad altri sistemi, come il controllo delle versioni semantico. Ma se nessuno sta davvero usando il tuo sistema di controllo delle versioni eccetto le persone che lo creano, non ha molta importanza.

Nella versione corrente di Versioning semantico, che è 2.0.0 , no. Esiste un requisito che definisce la versione come il modulo X.Y.Z dove X, Y e Z sono numeri interi non negativi che non contengono 0 iniziali:

A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.

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

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata SHOULD be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85.

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

Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. However it is done, it should be precise and comprehensive.

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

La cosa importante da considerare è che cosa significano i tuoi 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 semantiche è un metodo per mettere le regole attorno a questo, quindi se si sa che un'applicazione sta usando il Semantic Versioning, allora è più facile determinare il livello di sforzo richiesto per aggiornare i pacchetti. Seguire uno standard comune può essere buono, ma se non è possibile per qualsiasi motivo, anche la documentazione delle regole per gli utenti dovrebbe essere sufficiente.