Quale "convenzione di denominazione della versione" usi? [chiuso]

Mi trovo raramente d'accordo completamente con Jeff Atwood, ma tendo a seguire la sua opinione sulla convenzione .NET della numerazione delle versioni .

(Major version).(Minor version).(Revision number).(Build number)

Molto spesso, per i progetti personali, trovo che questo sia eccessivo. Le poche volte in cui ho lavorato a progetti sostanziali come i motori di ricerca in C # ho aderito a questa convenzione e sono stato in grado di usarlo come tracker interno in modo efficace.

Il versioning semantico ( link ) merita una menzione qui. È una specifica pubblica per uno schema di controllo delle versioni, sotto forma di [Major].[Minor].[Patch] . La motivazione di questo schema è comunicare il significato con il numero di versione.

Non lo uso ma ho visto ed è una struttura interessante:

Year.Month.Day.Build

Spiegazione personale.

Cerco di utilizzare la norma di Versioning Rational di RubyGems in cui:

• Il numero di versione principale viene incrementato quando la compatibilità binaria è interrotta
• Il numero di versione minore viene incrementato quando viene aggiunta una nuova funzionalità
• Il numero di build cambia per le correzioni dei bug.

Ecco un approccio molto dettagliato alla numerazione delle versioni:

• N.x.K , dove N e K sono numeri interi. Esempi: 1.x.0 , 5.x.1 , 10.x.33 . Utilizzato per build intermedie .
• N.M.K , dove N , M e K sono numeri interi. Esempi: 1.0.0 , 5.3.1 , 10.22.33 . Utilizzato per versioni .
• N.x.x , dove N è intero. Esempio: 1.x.x . Utilizzato per rami di supporto .
• N.M.x , dove N e M sono numeri interi. Esempio: 1.0.x . Utilizzato per rilascia rami .

Ecco l'illustrazione per una semplice illustrazione dell'approccio alla numerazione delle versioni:

PAsignificapre-alphaAsignificaalphaBsignificabetaARsignificaalpha-releaseBRsignificaversionebetaRCsignificareleasecandidateSTsignificastabile

Ivantaggiditaleapproccioallanumerazionedelleversionisonoiseguenti:

• Rappresentalespecifichedelciclodivitadellosviluppodelsoftwareagile.
• Prendeinconsiderazionelespecifichedellastrutturadelrepositorydelcodicesorgente.
• Èautoesplicativopercolorochesisonoabituatiaimodelli.Ognimodellorappresentaundiversoartefatto.Talimodellipossonoesserefacilmenteanalizzatieutilizzatiperaltriscopi,comeilmonitoraggiodeiproblemi.
• Setdimodellidicontrollodellaversione,cheperl'approcciodellaversionedescrittopossonoessereutilizzatiperraccoglieremetricheepianificazione.
• Siconcentrasuiconcettidimaturitàelivellodiqualità.Moltospessotalinumeridiversionecome1.0.0vengonoassegnatisenzamoltanecessità(quandoilsoftwareèindeepalpha).L'approccioallanumerazionedelleversionipresentatoconsentedistabilirediversilivellidimaturità.Nelcasopiùsempliceavràsoloduelivelli:buildintermedio(N.x.K)erilascio(N.M.K).Rilasciosignificacheunapartedelsoftwareconnumerodiversionecompleto(N.M.K)haattraversatounasortadiprocessodigestionedellaqualitàall'internodell'azienda/organizzazione/squadrafornitore.
• Èunaprovadinaturaagiledisviluppoetest.
• Incoraggiaapprocciomodulareallastrutturaeall'architetturadelsoftware.

C'èancheun diagramma più complesso che rappresenta l'approccio alla versione nei dettagli. Inoltre potresti trovare utili diapositive di presentazione che descrivono la transizione all'approccio di versioning e SCMFViz applicazione che illustra i principi di base dell'approccio della numerazione delle versioni. Le slide di presentazione spiegano anche perché è importante attenersi allo stesso approccio di versioning per tutta la durata del progetto software.

Personalmente, il mio atteggiamento nei confronti dell'uso della versione della data invece dei numeri di versione reali presuppone che gli sviluppatori del software con versioni datate:

• Non sapere nulla sul ciclo di vita dello sviluppo del software . Lo sviluppo è solitamente agile e iterativo. L'approccio alla numerazione delle versioni dovrebbe rappresentare la natura iterativa del processo di sviluppo del software.
• Non preoccuparti della qualità del software . Il controllo e la garanzia della qualità sono agili e iterativi. Proprio come lo sviluppo. E il numero di versione dovrebbe essere la prova della natura agile e iterativa sia dello sviluppo che del controllo / assicurazione della qualità.
• Non preoccuparti dell'architettura o idea della loro applicazione. Il numero di versione principale ( N in N.M.K ) è responsabile sia della soluzione architettonica che del principio di base dell'applicazione. Il numero di versione principale N deve essere modificato di conseguenza in base alle modifiche all'architettura o ai cambiamenti delle idee e dei principi principali del suo funzionamento / funzionamento.
• Non ha il controllo sulla base di codice . Probabilmente c'è solo un ramo (tronco) ed è usato per tutto. Che personalmente non penso sia giusto in quanto incoraggia la codebase a diventare un grande dump della spazzatura.

Questo approccio potrebbe sembrare un po 'controverso, ma credo che questo sia il modo più semplice per fornire numeri di versione appropriati al software.

Per ogni versione principale che si rilascia, non è raro avere una versione funzionante che si chiama internamente. Ad esempio, nel mio ultimo lavoro, ci siamo riferiti a una versione principale con la seguente convenzione di denominazione ispirata a Ubuntu:

[condizione malata] [nome animale allitterativo]

Che ha dato nomi come " Limp Lamprey ", " Wombed Wombat " e " Anthem astmatico ".

Accertati che a meno che non si tratti di un nome davvero interessante che non viene divulgato ai tuoi clienti.

Generation.Version.Revision.Build (9.99.999.9999)

La generazione cambia raramente. Solo un grosso giro di prodotti: DOS - > Windows, completa reingegnerizzazione.

La versione è per grandi cambiamenti incompatibili, nuove funzionalità, modifiche su alcuni paradigmi specifici sul software, ecc.

La revisione viene spesso eseguita (funzionalità minori e correzione di errori).

Costruisci sono informazioni interne.

git describe fornisce una bella estensione a qualsiasi convenzione di numerazione che hai scelto. È abbastanza facile incorporarlo nel processo di compilazione / creazione / distribuzione.

Supponiamo di nominare le versioni di rilascio codificate A.B.C (major.minor.maintenance). git describe su un dato commit troverà l'antenato taggato più recente del commit, quindi virerà sul numero di commit da quel momento, e il SHA1 abbreviato del commit:

1.2.3-164-g6f10c

Se sei effettivamente in una delle versioni, ovviamente, riceverai il tag (1.2.3).

Questo ha il vantaggio di farti sapere esattamente da quale fonte hai costruito, senza dover numerare ogni singola build.

Major.Minor.Public (build) [alpha / beta / trial], ad esempio "4.08c (1290)"

• Con Major è il numero di versione principale (1, 2, 3 ...)
• Minor è una versione secondaria di 2 cifre (01, 02, 03 ...). In genere, la cifra delle decine viene incrementata quando viene aggiunta una nuova funzionalità significativa, solo quelle per la risoluzione dei bug.
• Pubblico è la versione pubblica della build (a, b, c, d, e), che è spesso diversa dalla versione secondaria se una versione secondaria non viene mai rilasciata come aggiornamento pubblico
• build, essendo il numero di build effettivo di cui il compilatore tiene traccia.
• con TRIAL, ALPHA, BETA X o RC X aggiunti per quei casi speciali.

Preferisco i numeri di versione che assegnano un significato semantico. Finché puoi utilizzare il numero di versione per tenere traccia dei bug segnalati con una particolare versione alle modifiche avvenute nel codice sorgente (e nel tuo sistema di gestione delle attività), probabilmente stai usando il metodo giusto.

Io uso .NET quindi sono bloccato con il sistema di numerazione delle versioni .NET ma cerco di dare un significato semantico ai numeri così con

major.minor.build.revision

• major = (fino al progetto)
• minor = (fino al progetto)
• build = build numero da Hudson (puoi usare TeamCity o TeamBuild, ecc. Qui)
• revision = subversion o bazaar revisione (a seconda del progetto e a cosa serve)

Ci assicuriamo sempre che il numero di versione sia visibile in qualche modo (con i nostri programmi basati su console batch stampati su console e un file di registro, con le app Web nella barra dei menu in alto in genere)

In questo modo se i clienti segnalano problemi possiamo usare il numero di versione per tenere traccia se stanno usando la versione più recente e quanti problemi abbiamo avuto con determinate versioni.

È tutto sulla tracciabilità!

Usiamo Major.Minor.Build # .YYMMDD [suffisso], dato che di solito facciamo solo una build di produzione in un giorno particolare (ma usa il suffisso ab / c / d se ce n'è più di uno ) e la YYMMDD fornisce agli utenti / clienti / gestori un'indicazione dell'età della compilazione, dove non è 6.3.1389.

I numeri importanti aumentano con caratteristiche significative del prodotto (a pagamento).

I numeri minori aumentano con correzioni / miglioramenti (aggiornamento gratuito).

La build aumenta sempre; non tutte le build vengono spedite, quindi non è una progressione lineare.

I numeri di versione dovrebbero avere informazioni sufficienti per evitare conflitti e correggere un bug nei problemi di tipo di rilascio errati, ma non dovrebbero trasmettere informazioni aggiuntive non pertinenti.

Ad esempio se usi la data i clienti possono dire che hanno una versione precedente e le patch contro le vecchie versioni possono avere versioni confuse.

Personalmente mi piace versioning semantico :

• I rilasci sono Major . Minor . Patch
• Patch incrementa ogni volta che rilasci una build.
• Minor incrementa ogni volta che viene aggiunta la funzionalità compatibile all'indietro.
• Major incrementi quando la nuova funzionalità non è retrocompatibile.
• Quando Major == 0 sei in alpha / pre-rilascio. Major > = 1 sono le tue versioni pubbliche.
• I numeri più bassi vengono reimpostati su 0 ogni volta che si incrementa, quindi

  1.5.3 -> 1.5.4 (bug fix) -> 1.6.0 (minor feature) -> 2.0.0 (breaking change)

  

              1.0.0
                |
              1.0.1
                |
(public 1.0)  1.0.2-----
                |       \
              2.0.0    1.1.0
                |        |
              2.0.1    1.1.1 (public 1.1)
                |
(public 2.0)  2.0.2-----
                |       \
              3.0.0    2.1.0
                         |
                       2.1.1 (public 2.1)
                         |
                       2.2.0
                         |
                       2.2.1

X.Y.Z è il nostro numero di versione interno. X.Y è il numero di versione pubblica, quello che ha un significato per i nostri clienti. Quando una versione X.Y.Z diventa pubblica, non ci sarà mai una versione X.Y.(Z+1) : la versione pubblica è sempre l'ultima della serie.

X viene incrementato quando viene rilasciata una versione principale.

Y viene utilizzato per i rami di manutenzione di quelle versioni principali, solo per correzioni di bug.

Z è usato internamente e non ha un significato fisso. Fino ad ora, ho creato una nuova versione Z quando penso che l'applicazione abbia un insieme di caratteristiche interessanti da mostrare ai non sviluppatori ed è relativamente stabile. In questo modo, posso mostrare una demo dell '"ultima versione nota migliore" dell'applicazione quando qualcuno ne fa una. In un prossimo futuro, ho in programma di utilizzare le versioni del numero Z per nominare un "target" di funzionalità, nel nostro bugtracker.

Come nota a margine, usiamo Maven (con il comando release ) per incrementare il numero di versione. Quindi, ci sono anche% versioni di% di co_de (che indica qualsiasi versione tra X.Y.Z-SNAPSHOT e X.Y.(Z-1) ).