Come fare i numeri di versione?

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, in realtà non voglio la "sorveglianza instabile". 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!

[ major ]. [ minor ]. [ release ]. [ build ]

major : Davvero una decisione di marketing. Sei pronto a chiamare la versione 1.0? L'azienda 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 di ricerca e sviluppo e più una decisione di prodotto.

minor : inizia da 0 ogni volta che viene incrementato major . +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.

Esempi Il
mio chrome attuale: 83.0.4103.61

xyzg

gli incrementi in g sono instabili. (o RC) gli incrementi in z sono stabili e significano correzioni di errori.
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 è concretizzato, 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 versioning dei componenti rispetto al versioning 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 controllo delle versioni del numero di revisione si esaurirà.

Modifica: come riepilogo, distingue tra file sorgente di versioning, componenti e prodotto complessivo. Utilizza un sistema di xy separato per i componenti e il 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: Dal momento che un numero sufficiente di persone ha trovato utile il mio articolo per renderlo una "bella risposta", ho ricominciato a lavorare 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 riuscirò a trovare il tempo. Grazie per i tuoi voti!

Lasciati ispirare da Wikipedia: "Software versioning"

Un'altra opzione "nuova" e "relativamente popolare" è la versione semantica

Sommario:

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

1. Versione MAJOR quando apporti modifiche API incompatibili,
2. Versione MINORE quando si aggiunge funzionalità in modo compatibile con le versioni precedenti e
3. 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.

abcd

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

L'obbligatorio è quello più a sinistra, ad esempio se ci sono ad esempio una nuova funzionalità e un bug corretto, allora 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 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 del segmento di rilascio principale:

MARKETTING.MAJOR.MINOR.PATCH

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

Come SemVer, raccomando i componenti Major, Minor e Patch di rappresentare i livelli di compatibilità inversa, ma consiglio anche di anteporre un componente Marketing . Ciò consente ai proprietari di 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 di build al segmento principale. Invece, aggiungi 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 principale. 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 release 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 vogliono utilizzare un segmento di pre-rilascio per indicare pre-release 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 si dovrebbe urtare il segmento di rilascio contemporaneamente all'aggiunta del segmento di post-rilascio e quindi rilasciare il segmento di pre-rilascio quando successivamente si salta 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.

Il bello 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. Ciò è particolarmente importante quando si utilizzano sistemi di 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 rubino . Avevo bisogno non solo di utilizzare questo modello, ma anche di gestire altre app che lo utilizzavano.

I "numeri di versione" sono di competenza del sistema di controllo interno della versione. 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 è il rilascio di correzioni di bug o miglioramenti minori . Se segui il formato XY, 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, in quanto renderà difficile per distro, siti Web di annunci, ecc. Lavorare con te, e questo da solo potrebbe compromettere seriamente la popolarità del tuo progetto.

Usa rami e tag nel tuo sistema di controllo della versione (preferibilmente distribuito) per contrassegnare specifici numeri di versione interni come rispettivamente per 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 noterai cose che ci siamo persi". Qualunque cosa senza una di queste dovrebbe (idealmente, ovviamente) essere testata, conosciuta bene, 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.

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

Mentre andare con il numero di revisione di Subversion è semplice e carino, 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 "dall'esterno" (dal punto di vista dell'utente) determinare quando vengono effettuate le versioni e quante revisioni subiranno il codice tra loro, rende i numeri quasi casuali. Aumenteranno e credo che sia possibile ipotizzare una certa distanza dal confronto tra due revisioni, ma non molto.

I numeri di versione classici tendono a "drammatizzare" le versioni, in modo che gli utenti possano creare un qualche tipo di aspettativa. È più facile pensare "Ho la versione 1.0, ora la versione 1.1 è uscita aggiungendo questo e quello, sembra interessante" piuttosto che pensare "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 un po 'con i contatori dei numeri di revisione.

Schema di versione: [major]. [Minor]. [Devrel] [mark]
[major]: 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. Reimpostare su 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 n. di versioni pubbliche con nuove funzionalità: reimpostare su 1 ogni anno
• build = incrementato per correzioni di bug e rilasci interni

MODIFICARE

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

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

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 è semplicemente 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

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

1. Scegli uno schema per le revisioni numeriche e attenersi ad esso. Sii coerente.
2. Ogni cambio di versione dovrebbe rappresentare un cambiamento significativo . Quanto è piccolo un cambiamento significativo e quali sono i livelli di cambiamento che si riflettono nel numero di versione.

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

Spero che aiuti.

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 che non sono 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 giorno giuliano la build è stata inviata al QA.

L'esempio del primo rilascio inviato al QA in 1/15 è -> 1.0.015 L'
esempio del primo rilascio inviato in Produzione su 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'assembly 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 le stesse versioni di assembly non di spedizione tra 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, tuttavia, per build non di spedizione: 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.

Tuttavia, 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 ciascuna app senza dover utilizzare LoadFrom / etc.

Build di spedizione Se è una buona idea cambiare quella versione per 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'assembly Per modificare le versioni hardcoded in quella nuova, si consiglia di impostare una variabile sulla 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 "sovversione" numero di virgola .. zB:

1.0.101 // revisione 101, versione

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