Come fare i numeri di versione?

https://stackoverflow.com/questions/615227

03-07-2019
|

Domanda

La mia azienda sta costruendo un prodotto. Sta per essere versionato da SVN. È una webapp quindi praticamente non ci sarà mai una versione in uscita che non ha alcune caratteristiche e quindi potrebbe sempre essere etichettata come beta. Ma dal momento che sarà un prodotto aziendale, non voglio davvero il "watchtable instabile". là. Quindi come faresti per il controllo delle versioni? 1.0 è stabile? La data di costruzione deve essere nel numero di versione? Dimmi cosa ne pensate voi ragazzi!

Soluzione

[ principale ]. [ minori ]. [ stampa ]. [ costruire ]

major : davvero una decisione di marketing. Sei pronto a chiamare la versione 1.0? La società considera questa una versione principale per la quale i clienti potrebbero dover pagare di più o è un aggiornamento della versione principale attuale che può essere gratuita? Meno di una decisione R & amp; D e più una decisione sul prodotto.

minore : inizia da 0 ogni volta che viene incrementato maggiore . +1 per ogni versione che diventa pubblica.

rilascio : ogni volta che raggiungi un traguardo di sviluppo e rilasci il prodotto, anche internamente (ad esempio al QA), incrementalo. Ciò è particolarmente importante per la comunicazione tra i team dell'organizzazione. Inutile dire che non rilasciare mai la stessa "release" due volte (anche internamente). Ripristina a 0 su ++ ++ o major ++.

build : può essere una revisione SVN, trovo che funzioni meglio.

Altri suggerimenti

x.y.z.g

gli incrementi in g sono instabili. (o RC) gli incrementi in z sono stabili e significano correzioni di bug.
gli incrementi in y sono stabili e significano nuove funzionalità.
gli incrementi in x sono stabili, rilascio importante senza compatibilità con le versioni precedenti al 100%.

Una volta ho scritto un'elaborata "guida allo stile di versioning" per un mio grande progetto. Il progetto non si è materializzato, ma la guida di stile è ancora disponibile online . È la mia opinione personale, forse è utile (o di ispirazione) per te.

Attenzione, è un lungo testo e passa al controllo delle versioni dei componenti rispetto al controllo delle versioni del prodotto e cose del genere. Esprime anche opinioni forti su alcuni schemi di versioning popolari nella comunità OSS, ma li ho, quindi li esprimo. ; -)

Non sono d'accordo con l'uso del numero di revisione di Subversion, per esempio. Potresti voler mantenere una versione rilasciata mentre continui lo sviluppo in TRUNK, quindi imposterai un ramo di manutenzione - e il tuo numero di revisione delle versioni va giù per lo scarico.

Modifica: Come riepilogo, distingue tra file sorgente di versione, componenti e prodotto complessivo. Utilizza un sistema di x.y separato per componenti e prodotto, con una bella interdipendenza tra i due che rende banale quale versione del componente appartiene a quale versione del prodotto. Descrive anche come gestire i cicli alpha / beta / release / patch senza rompere il sistema. In realtà, è un modus operandi per l'intero ciclo di sviluppo, quindi potresti voler scegliere. ; -)

Modifica 2: Poiché un numero sufficiente di persone ha trovato utile il mio articolo per renderlo una "bella risposta", ho iniziato a lavorare nuovamente sull'articolo. Le versioni PDF e LaTeX sono ora disponibili, una nuova riscrittura che include un linguaggio migliore e una grafica esplicativa seguirà non appena riesco a trovare il tempo. Grazie per i tuoi voti!

Lasciati ispirare da Wikipedia: " Versione del software "

Un altro " nuovo " e "relativamente popolare" l'opzione è Versione semantica

Riepilogo:

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


versione MAJOR quando si apportano modifiche API incompatibili,

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

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


Sono disponibili etichette aggiuntive per i metadati pre-release e build   estensioni al formato MAJOR.MINOR.PATCH.

A.B.C.D

Incrementi: quando
- d : correzioni di bug
- c : manutenzione, ad es. miglioramento delle prestazioni
- b : nuove funzionalità
- a : modifica dell'architettura

L'obbligatorio è quello più rimasto, ad es. se ad esempio sono state risolte una nuova funzione e un bug, devi solo incrementare b .

Sulla base della mia esperienza con la complessa gestione delle dipendenze a livello di piattaforma aziendale e il versioning delle versioni, sono venuto a raccomandare un approccio che mi piace chiamare Versioning semi-semantico .

Fondamentalmente si basa su Semantic Versioning 2.0 ma non è altrettanto rigoroso.

Segmenti della versione semi-semantica:

<primary.release.segment>[-<pre.release.segment>][+<post.release.segment>]

Formato segmento di rilascio principale:

MARKETTING.MAJOR.MINOR.PATCH

Ogni segmento dovrebbe consentire caratteri alfanumerici, ma i numeri puri sono raccomandati per cambiamenti incrementali logici.

Come SemVer, raccomando componenti Major, Minor e Patch a rappresentare livelli di compatibilità inversa, ma consiglio anche di anteporre un componente di marketing . Ciò consente ai proprietari dei prodotti, alle epopee / ai gruppi di funzionalità e alle preoccupazioni aziendali di superare il componente principale indipendentemente dalle preoccupazioni di compatibilità tecnica.

A differenza di altre risposte, non ho raccomandato di aggiungere un numero Build al segmento principale. Aggiungi invece un Segmento post-rilascio seguendo un '+' (es: 1.1.0.0 + build.42). SemVer chiama questo metadata di build, ma penso che il segmento Post-Release sia più chiaro. Questo segmento è ottimo per dichiarare i dati del suffisso non correlati alle informazioni di compatibilità nel Segmento di rilascio primario. Alle build di integrazione continua può quindi essere assegnato il numero di versione precedente aggiunto con un numero di build incrementale che si reimposta dopo ogni versione principale (es: 1.1.0.0 - > 1.1.0.0 + build.1 - > 1.1.0.0 + build.2 - > 1.1.0.1). Ad alcune persone piace alternativamente inserire qui il numero di revisione svn o git commit sha per semplificare il collegamento al repository di codice. Un'altra opzione è quella di utilizzare il segmento post-release per hotfix e patch, quindi potrebbe valere la pena considerare l'aggiunta di un nuovo componente di rilascio primario per questo. Può sempre cadere quando il componente patch viene incrementato, poiché le versioni sono effettivamente allineate a sinistra e ordinate.

Oltre ai segmenti di rilascio e post-rilascio, le persone spesso desiderano utilizzare un Segmento di pre-rilascio per indicare pre-rilasci quasi stabili come alfa, beta e candidati al rilascio. L'approccio di SemVer a questo funziona bene, ma raccomando di separare i componenti numerici dai classificatori alfanumerici (es: 1.2.0.0 + alpha.2 o 1.2.0.0 + RC.2). Normalmente devi urtare il segmento di rilascio contemporaneamente all'aggiunta del segmento di post-rilascio e quindi rilasciare il segmento di pre-rilascio quando li salti successivamente il segmento di rilascio primario (es: 1.0.1.2 - > 1.2.0.0-RC.1 - > 1.2.0.0). I segmenti di pre-release vengono aggiunti per indicare che la versione di rilascio è in arrivo, di solito solo un set fisso di funzionalità per test più approfonditi e condivisione che non cambia minuto per minuto in base a più commit.

La bellezza di avere tutto questo semanticamente definito in un modo che copre quasi tutti i casi d'uso è che puoi analizzarli, ordinarli, confrontarli e incrementarli in modo standard. Questo è particolarmente importante quando si utilizzano sistemi CI per applicazioni complesse con molti piccoli componenti con versione indipendente (come i micro-servizi) ciascuno con le proprie dipendenze gestite.

Se sei interessato, ho scritto un parser semi-semantico in ruby ??. Avevo bisogno non solo di utilizzare questo modello, ma anche di gestire altre app che lo utilizzavano.

" Numeri di versione " sono una questione relativa al sistema di controllo della versione interna. I numeri di rilascio sono una questione diversa (e dovrebbero essere KEPT diversi).

Attenersi a un semplice sistema di rilascio MAJOR.MINOR (come v1.27), in cui MAJOR è il livello di compatibilità (la versione 2.x è incompatibile con o almeno sostanzialmente diversa dalla versione 1.x) e MINOR è la versione dei bugfix o miglioramenti minori. Se segui il formato X.Y, puoi anche utilizzare altri sistemi come YEAR.MONTH (2009.12) o YEAR.RELEASE (2009.3). Ma davvero stai probabilmente meglio attenersi a MAJOR.MINOR a meno che tu non abbia una buona ragione per non farlo.

Sicuramente non usare nulla che non si adatti al formato XY, poiché renderà difficile la collaborazione con distro, siti Web di annunci, ecc. e questo da solo potrebbe influenzare seriamente la popolarità del tuo progetto.

Usa i rami e i tag nel tuo sistema di controllo della versione (preferibilmente distribuito) per contrassegnare specifici numeri di versione interni relativi rispettivamente a MAJORS e MINORS.

E sì, 1.0 dovrebbe essere stabile. Tutte le versioni dovrebbero essere stabili, a meno che non siano contrassegnate come alfa, beta o RC. Usa Alpha per noto-rotto-e-incompleto. Betas per noto-rotto. RC per " provalo; probabilmente vedrai cose che ci siamo persi " ;. Qualunque cosa senza una di queste dovrebbe (idealmente, ovviamente) essere testata, ben nota, avere un manuale aggiornato, ecc.

In questi giorni è abbastanza popolare usare solo il numero di revisione di Subversion.

Se è in SVN, perché non usare il numero di revisione SVN?

Se guardi in basso a destra in questa pagina web vedrai il numero di versione di Stack Overflow che è il numero di revisione SVN.

Il controllo delle versioni dipende da te; Avrei messo 1.0 nella prima versione di cui ero fiducioso. Potresti voler seguirlo rapidamente con altre versioni, poiché alcuni produttori di software hanno dato alla 1.0 una cattiva reputazione.

Volete un modo per legare il numero di versione alla build esatta utilizzata, ma probabilmente volete che sia piacevole e semplice per i vostri utenti finali. Prendi in considerazione l'utilizzo dei numeri di versione standard e la codifica del repository SVN con il numero di versione incluso.

Anche se andare con il numero di revisione di Subversion è bello e semplice, rimuove le informazioni dal numero di versione. Gli utenti potrebbero considerarlo una cosa negativa.

Suppongo che la tua webapp avrà una sorta di procedura di distribuzione, in modo che non tutte le revisioni in Subversion siano effettivamente pubblicate. Dal momento che è impossibile da "fuori" (dal punto di vista dell'utente) per determinare quando vengono fatte le versioni e quante revisioni subiranno il codice tra loro, rende i numeri quasi casuali. Aumenteranno e credo che sia possibile supporre un po 'di distanza dal confronto tra due revisioni, ma non molto.

I numeri di versione classica tendono a "drammatizzare" rilasci, in modo che gli utenti possano creare qualche tipo di aspettativa. È più facile pensare "Ho la versione 1.0, ora la versione 1.1 è disponibile aggiungendo questo e quello, che sembra interessante" che pensare che ieri abbiamo eseguito la revisione SO 2587, oggi è 3233, deve essere molto meglio! " ;.

Naturalmente, anche questa drammatizzazione può essere gonfiata, con le aziende che scelgono i numeri di versione che dovrebbero sembrare più interessanti di quanto sia motivato dalle effettive differenze nel prodotto, immagino che andare con i contatori dei numeri di revisione sia un po '.

Schema di versione: [major]. [minor]. [devrel] [mark]
[maggiore]: incrementa se hai un drastico cambiamento nello sviluppo.
[minore]: incrementa se hai un piccolo cambiamento nello sviluppo.
[devrel]: increment se hai una correzione di bug. Resettare a zero se major ++ o minor ++.
[mark]: a, b o rc: a è un rilascio alfa, b è un rilascio beta e rc è un candidato al rilascio. Si noti che versioni come 1.3.57a o 1.3.57b o 1.3.57rc sono precedenti alla versione 1.3.57. Inizia da 0.0.0.

Abbiamo passato troppo tempo a decidere quando incrementare la versione principale. Alcuni negozi lo farebbero raramente, quindi avresti versioni come 1.25.3 e altri lo farebbero per sempre, dandoti 15.0

Mi sono stufato di questo e ho convinto tutti che il numero di rilascio principale è solo l'anno e il minore è solo un rilascio sequenziale entro l'anno. Agli utenti sembrava piacere ed è un gioco da ragazzi trovare il prossimo numero di versione.

Year.Release.build

anno = anno corrente
release = sequenza # di versioni pubbliche con nuova funzionalità: reimpostare su 1 ogni anno
build = incrementato per bug correzioni e versioni interne

MODIFICA

** Ora questo era per un'app interna che veniva continuamente migliorata **

Probabilmente questo non funzionerebbe per le app commerciali in cui è importante avere importanti versioni in diversi periodi dell'anno per scopi di marketing e finanziari.

Ho pochissima esperienza nella zona. Tuttavia, ecco cosa farei:

Scegli uno schema per la numerazione delle revisioni e attenersi ad esso. Sii coerente.
Ogni cambio di versione dovrebbe rappresentare un cambiamento significativo . Quanto è piccolo un cambiamento significativo e i livelli di cambiamento che si riflettono nel numero di versione dipendono da te.

Ovviamente, puoi semplicemente usare il numero di revisione svn --- come molti altri hanno suggerito !!!

Spero che questo aiuti.

Il motivo per cui esiste questa domanda è perché non abbiamo un unico modo concordato per eseguire la gestione della configurazione.

Il modo in cui mi piace fare il numero di versione è solo incrementare il numero intero da 1. Non voglio un numero di versione in più parti che dovrò spiegare o documentare. E non voglio usare il numero di giri SVN poiché ciò richiederà anche qualche spiegazione.

Avresti bisogno di alcuni script di rilascio sopra SVN per farlo accadere

Usiamo una semplice sintassi major.minor.julian_date.

Dove;

major: la prima versione è 1 e quindi quando introduciamo nuove importanti funzionalità o modifiche così significative da non essere compatibili con le versioni precedenti, aumenta questo numero.
minore: le principali versioni milestone. Per ogni build spinta dalla produzione questo numero aumenta.
julian_date - Il Julian Day la build è stata trasferita al QA.

L'esempio della prima versione inviata al QA in 1/15 è - > 1.0.015
Esempio del primo rilascio inviato a Production in 3/4 è - > 1.1.063

Non è perfetto, ma utile quando spingiamo le build al QA quasi ogni giorno.

Alcune buone informazioni qui:

Quando modificare le versioni di file / assembly

Prima di tutto, le versioni dei file e le versioni degli assiemi non devono necessariamente coincidere tra loro. Raccomando che le versioni dei file cambino ad ogni build. Tuttavia, non modificare le versioni dell'assieme con ogni build solo in modo da poter distinguere tra due versioni dello stesso file; usa la versione del file per quello. Decidere quando modificare le versioni dell'assieme prende in considerazione i tipi di build da considerare: spedizione e non spedizione.

Build non di spedizione In generale, consiglio di mantenere invariate le versioni dell'assembly non di spedizione tra le build di spedizione. In questo modo si evitano problemi di caricamento dell'assembly con nome sicuro dovuti a disallineamenti di versione. Alcune persone preferiscono utilizzare i criteri del publisher per reindirizzare nuove versioni di assembly per ogni build. Lo sconsiglio per le versioni non di spedizione, tuttavia: non evita tutti i problemi di caricamento. Ad esempio, se un partner copia x la tua app, potrebbe non sapere di installare i criteri del publisher. Quindi, l'app verrà interrotta per loro, anche se funziona perfettamente sulla tua macchina.

Ma, se ci sono casi in cui applicazioni diverse sulla stessa macchina devono associarsi a versioni diverse dell'assembly, ti consiglio di fornire a quelle build versioni dell'assembly diverse in modo che sia possibile utilizzare quella corretta per ogni app senza dover usare LoadFrom / etc.

Build di spedizione Se è una buona idea cambiare quella versione per le build di spedizione, dipende da come si desidera che l'associazione funzioni per gli utenti finali. Vuoi che queste build siano fianco a fianco o sul posto? Ci sono molti cambiamenti tra le due build? Stanno andando a rompere alcuni clienti? Ti interessa che li rompa (o vuoi forzare gli utenti a utilizzare i tuoi aggiornamenti importanti)? In caso affermativo, è necessario aumentare la versione dell'assembly. Ma, ancora una volta, considera che farlo troppe volte può sporcare il disco dell'utente con assiemi obsoleti.

Quando si modificano le versioni dell'assieme Per cambiare le versioni hardcoded con quella nuova, raccomando di impostare una variabile per la versione in un file di intestazione e di sostituire l'hardcoding nei sorgenti con la variabile. Quindi, esegui un pre-processore durante la compilazione per inserire la versione corretta. Raccomando di cambiare le versioni subito dopo la spedizione, non proprio prima, in modo che ci sia più tempo per rilevare i bug a causa della modifica.

O per usare il tuo numero di versione virgola "versione pensata". z.B:.

1.0.101 // revisione 101, versione

o 1.0.101-090303 // con data di rilascio, lo uso

Autorizzato sotto: CC-BY-SA insieme a attribuzione

Non affiliato a StackOverflow