Quale schema di numerazione delle versioni utilizzare?

Sto cercando uno schema di numerazione delle versioni che esprima l'estensione del cambiamento, in particolare la compatibilità.Quale schema di numerazione delle versioni utilizzare?

Apache APR, ad esempio, utilizzare il noto schema di numerazione versione

<major>.<minor>.<patch> 
example: 4.5.11

Maven suggerisce una simile ma più dettagliato schema:

<major>.<minor>.<patch>-<qualifier>-<build number> 
example: 4.5.11-RC1-3732

Dove è lo schema versioni Maven definita? Esistono convenzioni per il qualificatore e il numero di build? Probabilmente è una cattiva idea usare Maven ma non seguire lo schema di versione di Maven ...

Quali altri schemi di numerazione delle versioni conosci? Quale schema preferiresti e perché?

fonte

2010-01-12 deamon

http://stackoverflow.com/questions/1889615/version-numbering-basics help? – VonC

Questo è il current Maven version comparison algorithm e un discussion di esso. Finché le versioni crescono solo e tutti i campi tranne il numero di build vengono aggiornati manualmente, sei a posto. I qualificatori funzionano così: se uno è un prefisso dell'altro, più è più vecchio. Altrimenti vengono confrontati in ordine alfabetico. Usali per le versioni preliminari.

In secondo luogo l'uso del controllo delle versioni semantico per esprimere la compatibilità; major è per modifiche non retrocompatibili, minori per funzionalità compatibili con le versioni precedenti, patch per correzioni di bug compatibili con le versioni precedenti. Documentalo in modo che gli utenti della tua libreria possano esprimere correttamente le dipendenze sulla tua libreria. Le istantanee sono automatizzate e non è necessario incrementarle, tranne la prima istantanea dopo un rilascio a causa del modo in cui i prefissi vengono confrontati.

fonte

2010-01-12 11:27:55 Tobu

Vorrei raccomandare lo standard Semantic Versioning, che il sistema di controllo delle versioni di Maven sembra anche seguire. Si prega di verificare,

http://semver.org/

Insomma è <major>.<minor>.<patch><anything_else>, ed è possibile aggiungere regole aggiuntive alla parte qualsiasi altra cosa come sembra adatta a voi. per esempio. -<qualifier>-<build_number>.

fonte

2010-01-12 11:37:37 sixohsix

Lo schema - - di Maven sembra non corrispondere esattamente alla raccomandazione di semver.org. semver.org: "Un numero di versione speciale può essere indicato aggiungendo una stringa arbitraria ** immediatamente dopo ** la versione della patch.La stringa DEVE essere composta solo da caratteri alfanumerici più trattino [0-9A-Za-z-] e ** DEVE iniziare con un carattere alfa [A-Za-z] **. " – deamon

@deamon semver.org probabilmente lo ha cambiato anni fa, ma per la cronaca ora è conforme allo schema Maven: "Una versione pre-release PU MAY essere indicata aggiungendo un trattino e una serie di identificatori separati da punti immediatamente dopo la versione della patch. DEVE comprendere solo alfanumerici ASCII e trattino [0-9A-Za-z-]. Gli identificatori NON DEVONO essere vuoti Gli identificatori numerici NON DEVONO includere gli zeri iniziali. " – Kapep

@kapep: I formati non sono ancora completamente compatibili, perché l'algoritmo di confronto di il semere è molto più complicato di quello che usa Maven. Ma se ti limiti solo a "-RC1", "-RC2" o simili, dovresti stare bene. – sleske

Dopo aver letto un sacco di articoli/esegue il QA/FAQ/libri divento a pensare che [MAJOR]. [MINOR]. [REV] è più utile schema di controllo delle versioni per descrivere la compatibilità tra versione del progetto (versioni dello schema per sviluppatore, non per marketing).

PRINCIPALI modifiche è all'indietro incompatibili e richiedono la modifica nome del progetto, percorso dei file, GUID, ecc

MINORI cambiamenti è retrocompatibile. Contrassegna l'introduzione delle nuove funzionalità .

REV per la sicurezza/correzioni di errori. Compatibile con le versioni precedenti e successive.

Questo schema di controllo delle versioni ispirato libtool la semantica di versioning e dagli articoli:

http://www106.pair.com/rhp/parallel.html

NOTA: Consiglio anche fornire build///qualità personalizzati data informazioni come aggiuntivo (build numero, data di costruzione, nome del cliente, qualità di rilascio):

Hello app v2.6.34 per banca nazionale, 2011-05-03, beta, costruire

Ma queste informazioni non è informazioni delle versioni!

fonte

2011-10-11 18:24:00 gavenkoa

Solo per completezza, menzionerò lo old Apple standard for version numbers. Sembra che sia la versione principale. versione minore. versione bug. stage. revisione senza release. Stage è un codice elaborato dal set d (sviluppo), un (alfa), b (beta), o fc (nave cliente finale - più o meno la stessa di release candidate, credo) .

Le versioni stage e non-release vengono utilizzate solo per le versioni meno recenti.

Quindi, la prima versione di qualcosa potrebbe essere 1.0.0. Potresti aver rilasciato un bugfix come 1.0.1, una nuova versione (con più funzioni) come 1.1 e una riscrittura o un aggiornamento principale come 2.0. Se poi volessi lavorare verso 2.0.1, potresti iniziare con 2.0.1d1, 2.0.1d2, su 2.0.1d153 o qualsiasi cosa ti serva, quindi inviare 2.0.1a1 al QA e dopo aver approvato 2.0.1a37 , invia 2.0.1b1 ad alcuni scommettitori volenterosi, poi dopo 2.0.1b9 è sopravvissuto una settimana sul campo, masterizza 2.0.1fc1 e inizia a ricevere i signoff. Quando 2.0.1fc17 è diventato abbastanza, diventerebbe 2.0.1 e ci sarebbe stata molta gioia.

Questo formato era standardizzato abbastanza da contenere un formato binario compresso e routine di supporto nelle librerie per fare confronti.

fonte

2012-04-27 16:09:34

Puramente per completezza (:-)), vorrei sottolineare che IMHO richiede build separate per ogni fase (che questo schema implica) non è una buona idea. Almeno le build per il QA finale/test dovrebbero funzionare in produzione invariata. Qualsiasi differenza richiesta nel comportamento deve essere iniettata tramite la configurazione. Vedi per es. [Separa i build 'debug' e 'release'?] (Http://stackoverflow.com/questions/420343/separate-debug-and-release-builds). – sleske

@sleske Non penso che implichi compilazioni separate per ogni fase. Se ti trovi nella fase di beta test, creerai 1.2.3b4 in dev, inseriremo tale elemento in CI, ottieni il QA per approvarlo, esegui UAT, quindi lo distribuisco ai beta-tester, utilizzando lo stesso binario fino in fondo. Piuttosto, ciò che implica è che in qualsiasi momento, sai fino a che punto può arrivare una build, quindi sai quando commetti che verrà utilizzato solo in fase di sviluppo, inviato ai beta tester, rilasciato, ecc. C'è qualche duplicazione alle transizioni Ad esempio, se 1.2.3b10 supera il test beta, lo stesso codice diventerà probabilmente 1.2.3fc1, che non è l'ideale. –

Si noti che uno schema di numero di versione (come x.y.0 vs. x.y) può essere limitato da fattori esterni.

Si consideri che announcement for Git 1.9 (Januaury 2014):

una release candidate Git v1.9-RC2 è ora disponibile per i test presso i soliti posti.

Ho sentito voci che i vari strumenti di terze parti non piace il numeri di versione a due cifre (ad esempio, "Git 2.0") e iniziato barfing destra e sinistra quando gli utenti installano v1.9-rc1 .
Mentre si è tentati di deriderli per la loro premessa sciatta, sono anche pratico e non mi dispiacerebbe chiamare la versione imminente v1.9.per aiutarli.

Se andiamo questa strada (e io sono propenso a seguire questa strada in questo momento), il sistema di controllo delle versioni sarà:

La release candidate prossimo sarà v1.9.0-rc3, non v1.9-rc3;

La prima versione di manutenzione per v1.9.0 sarà v1.9.1 (e l'altra sarà v1.9.N); e

La versione successiva alla v1.9.0 sarà v1.10.0 o v2.0.0, a seconda di quanto grande è il salto di funzionalità che stiamo osservando.

fonte

2014-02-04 07:30:33 VonC

Quale schema di numerazione delle versioni utilizzare?

risposta

Problemi correlati