it-swarm.it

Quale "convenzione di denominazione della versione" usi?

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

Personalmente, preferisco un numero di build in esadecimale (ad esempio 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.
111
rjstelling

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.

47
Mike B

Semantic Versioning ( 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.

90
M. Dudley

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

Year.Month.Day.Build

Auto spiegato.

33
Maniero

Provo a usare RubyGems Rational Versioning policy 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.
14
Ken Bloom

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 rilasci.
  • 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 rami di rilascio.

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

Agile version numbering

PA significa pre-alpha A significa alpha B significa beta AR significa alpha-release BR significa beta-release RC significa rilascio candidato ST significa stabile

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

  • Rappresenta le specifiche di agile ciclo di vita dello sviluppo del software.
  • Tiene conto delle specifiche di struttura del repository del codice sorgente.
  • È autoesplicativo 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.
  • Impostare i modelli di versione, quale base per l'approccio di versione descritto può essere utilizzato per raccolta 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: build intermedia (N.x.K) e release (N.M.K). Rilascio indica quel software con il numero di versione completo (N.M.K) ha attraversato una sorta di processo di gestione della qualità all'interno dell'azienda/organizzazione/squadra del fornitore.
  • È una prova di natura agile sia dello sviluppo che dei test.
  • Incoraggia approccio modulare alla struttura e all'architettura del software.

C'è anche un più complesso diagramma che rappresenta l'approccio di versioning in dettaglio. Inoltre potresti trovare utili slide di presentazione che descrivono la transizione all'approccio di versioning e SCMFViz applicazione che illustra 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 di versione della data invece dei numeri di versione reali presuppone che gli sviluppatori del software con versioni datate:

  • Non si conosce 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 idea della loro applicazione. Numero di versione principale (N in N.M.K) è responsabile sia della soluzione architettonica sia del principio alla base dell'applicazione. Il numero di versione principale N deve 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.

10
altern

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.

8
Jesse C. Slicer

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.

7
Maniero

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

Supponiamo di nominare le versioni di rilascio con tag A.B.C (major.minor.maintenance). git describe su un determinato commit troverà l'antenato con tag più recente del commit, quindi attaccherà il numero di commit da allora e il SHA1 abbreviato 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 singolo build da solo.

6
Cascabel

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 in qualche modo visibile (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 usando l'ultima versione e quanti problemi abbiamo avuto con particolari versioni.

Si tratta di tracciabilità!

2
Jeffrey Cameron

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.
2
GrandmasterB

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 il YYMMDD fornisce agli utenti/clienti/dirigenti un'indicazione dell'età della build, mentre 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.

1
JBRWilkinson
 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 della 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 tali versioni principali, solo per le correzioni di errori.

Z viene utilizzato internamente e non ha un significato fisso. Fino ad ora, ho creato una nuova versione Z quando penso che l'applicazione abbia una serie di funzionalità che sono interessanti da mostrare ai non sviluppatori ed è relativamente stabile. In questo modo, posso mostrare una demo dell '"ultima buona versione conosciuta" dell'applicazione quando qualcuno lo chiede. In un prossimo futuro, ho intenzione di utilizzare le versioni numeriche 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 X.Y.Z-SNAPSHOT Versioni (che indica qualsiasi versione tra X.Y.(Z-1) e X.Y.Z).

0
barjak