Come fare i numeri di versione?

La mia azienda sta costruendo un prodotto. Sarà versionato da SVN. È una webapp quindi in pratica non ci sarà mai una versione che non ha alcune caratteristiche in essa e quindi potrebbe sempre essere etichettata come beta. Ma dal momento che sarà un prodotto aziendale, non voglio davvero la “sorveglianza instabile”. Quindi come andresti sul versioning? 1.0 è stabile? La data di costruzione dovrebbe essere nel numero di versione? Dimmi cosa ne pensate voi ragazzi!

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

importante : davvero una decisione di marketing. Sei pronto per 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 corrente che potrebbe essere gratuita? Meno di una decisione di R & S e più una decisione sul prodotto.

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

Rilascio : ogni volta che raggiungi una pietra miliare dello sviluppo e rilasci il prodotto, anche internamente (ad esempio al QA), incrementalo. Questo è particolarmente importante per la comunicazione tra i team nell’organizzazione. Inutile dire che non rilasciano mai la stessa “versione” due volte (anche internamente). Resetta a 0 su minore ++ o maggiore ++.

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

xyzg

gli incrementi in g sono instabili. (o RCs) incrementi in z sono correzioni stabili e medie.
gli incrementi in y sono stabili e significano nuove funzionalità.
gli incrementi in x sono stabili, versione principale senza compatibilità al 100% all’indietro.

Una volta ho scritto una elaborata “guida al versioning style” per un mio grande progetto. Il progetto non si è concretizzato, ma la guida allo stile è ancora disponibile online . È la mia opinione personale, forse è utile (o di ispirazione) a voi.

Attenzione, è un testo lungo e va in versionazione dei componenti rispetto alla versione del prodotto e cose del genere. Esprime anche forti opinioni su alcuni programmi 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 dovrai configurare un ramo di manutenzione e il numero di versione del tuo numero di revisione andrà a buon fine.

Modifica: come riepilogo, distingue tra i file di origine delle versioni, i componenti e il prodotto generale. Utilizza un sistema di xy versoning separato per i componenti e il prodotto, con una bella interdipendenza tra i due che rende traccia di quale versione del componente appartiene a quale versione del prodotto è insignificante. Parla anche di 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: dato che un numero sufficiente di persone ha trovato utile il mio articolo per rendere questa una “Buona risposta”, ho ricominciato a lavorare sull’articolo. Le versioni PDF e LaTeX sono ora disponibili, una riscrittura completa che include una migliore lingua e una grafica esplicativa seguiranno non appena posso trovare il tempo. Grazie per i tuoi voti!

Fatti ispirare da Wikipedia: “Software versioning”

Un’altra opzione “nuova” e “relativamente popolare” è la Versione Semantica

Sommario:

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

  1. Versione MAJOR quando si apportano modifiche API incompatibili,
  2. Versione MINORE quando si aggiungono funzionalità in un modo compatibile con le versioni precedenti e
  3. Versione PATCH quando si effettuano correzioni di errori compatibili con le versioni precedenti.

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

abcd

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

L’obbligatorio è il più a sinistra, ad esempio se ci sono per esempio una nuova funzionalità e un bug corretto, allora devi solo incrementare b .

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

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

Segmenti di versione semi-semantica:

 [-][+] 

Formato segmento di rilascio primario:

MARKETTING.MAJOR.MINOR.PATCH

Ogni segmento dovrebbe consentire i caratteri alfanumerici, ma i numeri puri sono consigliati per le modifiche logiche incrementali.

Come SemVer, raccomando i componenti Major, Minor e Patch per rappresentare i livelli di compatibilità inversa, ma consiglio anche di prependere un componente Marketing . Ciò consente ai proprietari dei prodotti, alle funzioni di epic / gruppi e ai problemi aziendali di urtare il componente principale indipendentemente dai problemi di compatibilità tecnica.

A differenza di altre risposte, non è consigliabile aggiungere un numero di build al segmento principale. Invece, aggiungi un segmento Post-Release 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 è ideale per dichiarare i dati del suffisso come non correlati alle informazioni sulla compatibilità nel segmento di rilascio principale. Le build di integrazione continua possono quindi essere fornite con il numero di versione precedente aggiunto con un numero di build incrementale che si reimposta dopo ogni versione primaria (ad esempio: 1.1.0.0 -> 1.1.0.0 + build.1 -> 1.1.0.0 + build.2 -> 1.1.0.1). Alcune persone alternativamente amano mettere il numero di revisione svn qui o il commit git per renderlo più facile da bind al repository del codice. Un’altra opzione è quella di utilizzare il segmento post-rilascio per hotfix e patch, per cui potrebbe valere la pena di prendere in considerazione 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 di post-rilascio, le persone spesso desiderano utilizzare un segmento di pre-rilascio per indicare pre-release quasi stabili come alphas, beta e release candidate. L’approccio SemVer a questo funziona bene, ma vi consiglio 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 battere il segmento di rilascio contemporaneamente all’aggiunta del segmento post-rilascio e quindi rilasciare il segmento di pre-rilascio quando si urta il segmento di rilascio primario (es: 1.0.1.2 -> 1.2.0.0-RC.1 – > 1.2.0.0). I segmenti pre-rilascio vengono aggiunti per indicare che la versione di rilascio è in arrivo, di solito solo un set fisso di funzionalità per test e condivisione più approfonditi che non cambiano da minuto a 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 analizzare, ordinare, confrontare e incrementare in modo standard. Questo è particolarmente importante quando si usano sistemi CI per applicazioni complesse con molti piccoli componenti con versioni indipendenti (come i micro-servizi) ciascuno con le proprie dipendenze gestite.

Se sei interessato, ho scritto un parser semi-semantico in ruby . Non avevo solo bisogno di usare questo schema, ma di essere in grado di gestire altre app che lo utilizzavano.

Oggigiorno è piuttosto popolare usare solo il numero di revisione di Subversion.

I “numeri di versione” sono di competenza del sistema di controllo della versione interno. I numeri di rilascio sono diversi (e dovrebbero essere diversi da KEPT).

Attenersi a un semplice sistema di rilascio MAJOR.MINOR (come v1.27), in cui MAJOR è il livello di compatibilità (la versione 2.x è incompatibile o almeno sostanzialmente diversa dalla versione 1.x) e MINOR sono le versioni bugfix o miglioramenti minori . Se segui il formato XY, puoi anche utilizzare altri sistemi come YEAR.MONTH (2009.12) o YEAR.RELEASE (2009.3). Ma in realtà probabilmente stai meglio attaccare 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 per distro, siti web di annunci, ecc. Lavorare con te e questo da solo potrebbe compromettere seriamente la popolarità del tuo progetto.

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

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 Alphas per noto-rotto-e-incompleto. Betas per noto-rotto. RC per “provalo, probabilmente vedrai cose che abbiamo perso”. Qualunque cosa senza uno di questi dovrebbe (idealmente, ovviamente) essere testato, conosciuto bene, avere un manuale aggiornato, ecc.

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 Overflow dello stack che è il numero di revisione SVN.

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

Tu vuoi un modo per bind il numero di versione alla build esatta usata, ma probabilmente vuoi che sia bello e semplice per i tuoi utenti finali. Prendi in considerazione l’uso di numeri di versione standard e codifica del repository SVN con il numero di versione incluso.

Mentre andare con il numero di revisione di Subversion è semplice e semplice, rimuove le informazioni dal numero di versione. Gli utenti potrebbero considerare questa cosa negativa.

Presumo che la tua webapp abbia una sorta di procedura di distribuzione, in modo che non tutte le revisioni in Subversion vengano effettivamente pubblicate. Dal momento che è imansible da “fuori” (dal punto di vista dell’utente) determinare quando vengono rilasciati i rilasci e quante revisioni il codice subirà tra di loro, rende i numeri quasi casuali. Aumenteranno, e immagino sia ansible ipotizzare una qualche distanza dal confronto di due revisioni, ma non di molto.

I numeri di versione classica tendono a “drammatizzare” i 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 è uscita aggiungendo questo e quello, sembra interessante” che pensare “ieri abbiamo eseguito SO revisione 2587, oggi è 3233, deve essere molto meglio!”.

Naturalmente, anche questa drammatizzazione può essere gonfiata, con le aziende che scelgono i numeri di versione che sono destinati a sembrare più interessanti di quanto non siano motivati ​​dalle reali differenze nel prodotto, suppongo che si stia muovendo un po ‘con i contatori dei numeri di revisione.

Schema di versione: [maggiore]. [Minore]. [Devto] [segno]
[maggiore]: incrementa se hai un drastico cambiamento nello sviluppo.
[minore]: incrementa se hai un piccolo cambiamento nello sviluppo.
[devrel]: incrementa se hai una correzione di bug. Resetta a zero se maggiore ++ o minore ++.
[mark]: a, b o rc: a è una versione alpha, b è una versione beta e rc è una release candidate. Nota 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 impiegato troppo tempo per 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 stancato di questo e ho convinto tutti che il numero di rilascio principale è solo l’anno e il minore è solo una versione sequenziale entro l’anno. Sembrava che gli utenti lo apprezzassero ed è un gioco da ragazzi arrivare al prossimo numero di versione.

Year.Release.build

  • anno = anno corrente
  • release = sequence # of public releases con nuove funzionalità – ripristina 1 ogni anno
  • build = incrementato per correzioni di bug e versioni interne

MODIFICARE

** Ora questo era per un’app interna che è stata continuamente migliorata **

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

Ho pochissima esperienza nella zona. Tuttavia, ecco cosa dovrei fare:

  1. Scegli uno schema per la numerazione delle revisioni e attenersi ad esso. Sii coerente.
  2. Ogni modifica della 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.

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

Spero che aiuti.

Il motivo per cui esiste questa domanda è perché non abbiamo un unico modo concordato per fare 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 rev. SVN in quanto ciò richiederà anche qualche spiegazione.

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

Usiamo una semplice syntax major.minor.julian_date.

Dove;

  • major – La prima versione è 1 e poi quando introduciamo nuove importanti funzionalità o modifiche così significative che non sono retrocompatibili aumentano questo numero.
  • minor – Le principali pubblicazioni importanti. Per ogni build spinto dalla produzione questo numero aumenta.
  • julian_date – The Julian Day: la build è stata spinta al QA.

L’esempio della prima versione inviata a QA su 1/15 è -> 1.0.015
L’esempio della prima versione inviata a Production su 3/4 è -> 1.1.063

Non è perfetto, ma man mano che spingiamo le build al QA quasi quotidianamente.

Alcune buone informazioni qui:

Quando cambiare le versioni di file / assieme

Prima di tutto, le versioni dei file e le versioni di assemblaggio non devono necessariamente coincidere. Raccomando che le versioni dei file cambino con ogni build. Ma, non modificare le versioni di 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 cambiare le versioni di assemblaggio richiede una discussione sui tipi di build da considerare: spedizione e non spedizione.

Generazioni non di spedizione In generale, si consiglia di mantenere invariate le versioni di assembly non di spedizione tra le versioni di spedizione. Ciò evita problemi di caricamento di assembly con nome elevato a causa di mancate corrispondenze di versione. Alcune persone preferiscono utilizzare la politica dei publisher per redirect le nuove versioni di assembly per ogni build. Vi raccomando tuttavia di non farlo per le versioni non di spedizione: non evita tutti i problemi di caricamento. Ad esempio, se un partner x-copia la tua app, potrebbe non sapere di installare la politica dei publisher. Quindi, la tua app sarà danneggiata, anche se funziona correttamente sul tuo computer.

Ma, se ci sono casi in cui applicazioni diverse sulla stessa macchina devono legarsi a diverse versioni del tuo assembly, ti consiglio di dare a quelle build versioni di assembly differenti in modo che sia ansible utilizzare quella corretta per ogni app senza dover usare LoadFrom / etc.

Build di spedizione Per quanto riguarda la necessità di cambiare la versione per le build di spedizione, dipende da come si desidera che l’associazione funzioni per gli utenti finali. Vuoi che queste build siano side-by-side o sul posto? Ci sono molti cambiamenti tra le due build? Stanno andando a rompere alcuni clienti? Ti interessa che li spezzi (o vuoi forzare gli utenti a usare i tuoi aggiornamenti importanti)? Se sì, dovresti considerare di incrementare la versione dell’assembly. Ma, ripeto, considera che farlo troppe volte può sporcare il disco dell’utente con assiemi obsoleti.

Quando si modificano le versioni di assembly Per modificare le versioni con hardcoded in quella nuova, si consiglia di impostare una variabile per la versione in un file di intestazione e sostituire la codifica in codice con la variabile. Quindi, esegui un pre-processore durante la compilazione per inserire la versione corretta. Raccomando di cambiare versione subito dopo la spedizione, non prima, in modo che ci sia più tempo per catturare i bug a causa del cambiamento.

O per usare il numero di versione del tuo numero di “virgola” versione virgola .. zB:

1.0.101 // revisione 101, versione

o 1.0.101-090303 // con la data di rilascio, io uso questo