Quale "convenzione di denominazione delle versioni" usi? [chiuso]

Convenzioni di denominazione di versioni diverse sono adatte a progetti diversi? Cosa usi e perché?

Personalmente, preferisco un numero di build in esadecimale (ad es. 11BCF), che dovrebbe essere incrementato molto regolarmente. E poi per i clienti un semplice numero di versione a 3 cifre, ovvero 1.1.3.

1.2.3 (11BCF) <- Build number, should correspond with a revision in source control
^ ^ ^
| | |
| | +--- Minor bugs, spelling mistakes, etc.
| +----- Minor features, major bug fixes, etc.
+------- Major version, UX changes, file format changes, etc.

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

(Versione principale). (Versione secondaria). (Numero di revisione). (Numero di build)

Il più delle volte, 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 # mi sono attenuto a questa convenzione e sono stato in grado di usarlo come tracker interno in modo efficace.

La versione semantica ( http://semver.org/ ) merita una menzione qui. È una specifica pubblica per uno schema di versioning, sotto forma di [Major].[Minor].[Patch]. La motivazione di questo schema è di comunicare il significato con il numero di versione.

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

Year.Month.Day.Build

Auto spiegato.

Provo ad usare la politica di Rational Versioning di RubyGems in cui:

• Il numero di versione principale viene incrementato quando viene interrotta la compatibilità binaria
• Il numero di versione secondario viene incrementato quando si aggiunge una nuova funzionalità
• Il numero di build cambia per le correzioni di bug.

Ecco un approccio molto dettagliato alla numerazione delle versioni:

• N.x.K, dove Ne Ksono numeri interi. Esempi: 1.x.0, 5.x.1, 10.x.33. Utilizzato per build intermedie .
• N.M.K, Dove N, Me Ksono numeri interi. Esempi: 1.0.0, 5.3.1, 10.22.33. Utilizzato per le versioni .
• N.x.x, dove Nè intero. Esempio: 1.x.x. Utilizzato per le filiali di supporto .
• N.M.x, dove Ne Msono numeri interi. Esempio: 1.0.x. Utilizzato per i rami di rilascio .

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

PAsignifica pre-alfa A significa alfa B significa beta AR significa rilascio alfa BR significa rilascio beta RC significa rilascio candidato ST significa stabile

I vantaggi di tale approccio alla numerazione delle versioni sono i seguenti:

• Rappresenta le specifiche del ciclo di vita dello sviluppo software agile .
• Tiene conto delle specifiche della struttura del repository del codice sorgente .
• Si spiega da sé per coloro che si sono abituati ai modelli. Ogni modello rappresenta artefatto diverso. Tali modelli possono essere facilmente analizzati e utilizzati per altri scopi, come il rilevamento dei problemi.
• Set di modelli di versione, che di base per l'approccio di versione descritto può essere utilizzato per la raccolta di metriche e pianificazione .
• Si concentra sui concetti di maturità e livello di qualità . Molto spesso numeri di versione come 1.0.0 vengono assegnati senza necessità (quando il software è in alpha profondo). L'approccio alla numerazione delle versioni presentato consente di stabilire diversi livelli di maturità. Nel caso più semplice avrà solo due livelli: intermedio build ( N.x.K) e release ( N.M.K). Rilascio significa che un pezzo di software con il numero di versione completo ( N.M.K) ha attraversato una sorta di processo di gestione della qualità all'interno della società / organizzazione / squadra del fornitore.
• È una prova della natura agile sia dello sviluppo che dei test.
• Incoraggia l'approccio modulare alla struttura e all'architettura del software.

C'è anche un diagramma più complesso che rappresenta l'approccio al versioning in dettaglio. Inoltre, potresti trovare utili diapositive di presentazione che descrivono la transizione all'approccio di versioning e l' applicazione SCMFViz che illustrano i principi di base dell'approccio di numerazione delle versioni. Le diapositive di presentazione spiegano anche perché è importante attenersi allo stesso approccio di versioning per tutta la vita del progetto software.

Personalmente il mio atteggiamento nei confronti dell'utilizzo della versione della data anziché dei numeri della versione reale presuppone che gli sviluppatori del software con versioni datate:

• Non si sa nulla del ciclo di vita dello sviluppo del software . Lo sviluppo è di solito 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 / garanzia della qualità.
• Non preoccuparti dell'architettura o dell'idea della loro applicazione. Il numero di versione principale ( Nin N.M.K) è responsabile sia della soluzione architettonica sia del principio alla base dell'applicazione. Il numero di versione principale Ndeve essere modificato di conseguenza ai cambiamenti nell'architettura o ai cambiamenti delle idee e dei principi principali del suo funzionamento / funzionamento.
• Non hanno il controllo sulla loro base di codice . Probabilmente c'è solo un ramo (tronco) ed è usato per tutto. Che personalmente non penso sia giusto in quanto incoraggia codebase a diventare una grande discarica.

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

Per ogni versione principale che rilasci, non è raro avere una versione funzionante che la chiami internamente. Ad esempio, nel mio ultimo lavoro, abbiamo fatto riferimento a una versione principale con la seguente convenzione di denominazione ispirata a Ubuntu:

[condizione malata] [nome animale alliterativo]

Che ha dato nomi come " Limp Lamprey ", " Wounded Wombat " e " Asthmatic Anteater ".

Assicurati che a meno che non sia un nome davvero interessante che non perda per i tuoi clienti.

Generation.Version.Revision.Build (9.99.999.9999)

La generazione cambia raramente. Solo una grande svolta sul prodotto: DOS -> Windows, reingegnerizzazione completa.

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

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

Build è informazione interna.

git describefornisce una piacevole estensione a qualunque convenzione di numerazione tu abbia scelto. È abbastanza facile incorporarlo nel processo di compilazione / packaging / distribuzione.

Supponiamo di nominare le versioni di rilascio con tag ABC (major.minor.maintenance). git describesu un determinato commit troverà l'antenato con tag più recente del commit, quindi controllerà il numero di commit da allora e l'abbreviazione SHA1 del commit:

1.2.3-164-g6f10c

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

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

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

• Con Major è il numero di versione principale (1, 2, 3 ...)
• Minore è una versione minore di 2 cifre (01, 02, 03 ...). In genere la cifra delle decine viene incrementata quando vengono aggiunte nuove funzionalità significative, solo quelle per le correzioni di bug.
• Essendo pubblico il rilascio pubblico della build (a, b, c, d, e), che è spesso diverso dalla versione secondaria se una versione secondaria non viene mai rilasciata come aggiornamento pubblico
• build, ovvero il numero di build effettivo di cui tiene traccia il compilatore.
• con TRIAL, ALPHA, BETA X o RC X aggiunti per quei casi speciali.

Preferisco i numeri di versione che assegnano un significato semantico. Finché è possibile utilizzare il numero di versione per tenere traccia dei bug segnalati con una versione particolare alle modifiche verificatesi nel codice sorgente (e nel sistema di gestione delle attività), probabilmente si sta utilizzando il metodo giusto.

Uso .NET, quindi sono bloccato con il sistema di numerazione delle versioni di .NET, ma provo a dare un significato semantico ai numeri così

major.minor.build.revision

• major = (fino al progetto)
• minor = (fino al progetto)
• build = build number di Hudson (puoi usare TeamCity o TeamBuild, ecc. qui)
• revisione = sovversione o revisione del bazar (a seconda del progetto e del suo utilizzo)

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

In questo modo se i clienti segnalano problemi, possiamo usare il numero di versione per tracciare se stanno utilizzando l'ultima versione e quanti problemi abbiamo riscontrato con particolari versioni.

Si tratta di tracciabilità!

Usiamo Major.Minor.Build # .YYMMDD [suffisso], poiché di solito eseguiamo solo una build di produzione in un determinato giorno (ma usiamo il suffisso ab / c / d se ce n'è più di uno) e YYMMDD offre agli utenti / clienti / gestione un'indicazione dell'età della costruzione, dove il 6.3.1389 no.

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

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

La build aumenta sempre; non tutte le navi costruiscono, quindi non è una progressione lineare.

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

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

Personalmente mi piace il versioning semantico :

• Le versioni sono Major. Minor.Patch
• Patch aumenta ogni volta che rilasci una build.
• Minor aumenta ogni volta che viene aggiunta una funzionalità compatibile con le versioni precedenti.
• Major aumenta quando la nuova funzionalità non è compatibile con le versioni precedenti.
• Quando Major== 0 sei in alpha / pre-release. 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(correzione di bug) -> 1.6.0(caratteristica minore) -> 2.0.0(modifica della rottura)

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

X.Y.Zè il nostro numero di versione interno. X.Yè il numero di versione pubblico, quello che ha un significato per i nostri clienti. Quando una X.Y.Zversione diventa pubblica, non ci sarà mai una X.Y.(Z+1)versione: 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 tali versioni principali, solo per le correzioni di bug.

Zviene utilizzato internamente e non ha un significato fisso. Fino ad ora, creo una nuova Zversione quando penso che l'applicazione abbia una serie di funzionalità interessanti da mostrare ai non sviluppatori ed è relativamente stabile. In questo modo, posso mostrare una demo dell '"ultima versione valida conosciuta" dell'applicazione quando qualcuno lo chiede. In un prossimo futuro, ho intenzione di utilizzare le Zversioni numeriche per nominare un "target" di funzionalità, nel nostro bugtracker.

Come nota a margine, usiamo maven (con il releasecomando) per incrementare il numero di versione. Quindi, ci sono anche X.Y.Z-SNAPSHOTversioni (che indica qualsiasi versione tra X.Y.(Z-1)e X.Y.Z).