Qual è il modo corretto di gestire la versione dell'assieme?

Question

Non vedo l'ora di implementare una build giornaliera per un prossimo progetto.

Ma prima di farlo, devo sapere come eseguire correttamente la versione di un assembly.

Ho le seguenti preoccupazioni:

• Ogni assembly deve avere un numero di versione indipendente o devono condividere tutti la stessa versione?
• Devo usare una * versione per compilazione e revisione?
• La revisione è rilevante per la compilazione quotidiana?

Answer 1

Stampiamo tutti gli assemblaggi all'interno dei nostri prodotti con lo stesso numero di versione utilizzando i seguenti passaggi:

• Collega tutti gli assiemi a un AssemblyInfoCommon.cs contenente il file informazioni sul numero di versione: vedi qui per un esempio.

• Genera il file AssemblyInfoCommon.cs come parte della build usando (nel nostro caso) l'attività NAnt asminfo, Cruise Control .NET e l'etichettatrice di revisione SVN

Nel nostro caso, non utilizziamo la versione *. Tutte le versioni distribuite sono costruite sul server di build. Non ci preoccupiamo del numero di versione sui nostri desktop.

Answer 2

La risposta dipende in realtà da ciò che si sta tentando di ottenere con i numeri di versione dell'assembly. Se si sta eseguendo una distribuzione ClickOnce e si desidera eseguire download indipendenti di assembly aggiornati, è necessario disporre di ogni assembly indipendentemente dalla versione, altrimenti penso che sia spesso bello avere versioni di assembly corrispondenti al numero di versione del software. In scenari più complessi potresti aver bisogno di un'altra strategia.

Uno schema che avevo usato in un'azienda precedente era major.minor.revision.build, quindi nella versione 1.0 del prodotto, la versione dell'assembly e la versione del file dell'assembly su ciascun assembly era 1.0.0.1129 (ad esempio). Ciò ha reso facile abbinare quali assembly facevano parte di quale versione del software, fino al numero di build. Abbiamo ottenuto questo risultato utilizzando una ricerca di pre-compilazione e sostituendo in ciascun file AssemblyInfo.cs per sostituire un token con i numeri di versione forniti dal nostro processo di compilazione automatizzato.

Answer 3

Quindi ogni assembly dovrebbe avere la stessa versione che è in genere una combinazione della versione di rilascio ovvero 3.4 + il numero di build che è una sequenza che rappresenta il numero di volte che la versione è stata compilata sul server di build. La revisione è rilevante perché dimostra il numero di build che hai creato per quella versione. Puoi davvero farlo in 2 modi. Il primo modo sarebbe che se hai pianificato una versione, ad esempio 3.4, quando inizi a lavorare su quella versione, questo è il tuo numero di versione principale e il tuo numero di versione minore aumenta con la build. Un altro modo per farlo è controllare strettamente le versioni di build in quanto quando si è pronti per eseguire il rilascio in QA / Regressione si imposta la versione principale su 3.4 e si lascia il numero di versione minore su 0. Mantenere le cose strettamente controllate in questo modo fino al rilascio. In questo modo è possibile controllare la numerazione del service pack tramite il numero di versione secondario. Spero che questo aiuti.

Answer 4

Normalmente concordo sul fatto che tutti gli assembly devono avere lo stesso numero di versione; tuttavia, vorrei fare un avvertimento a questo. Se uno degli assiemi viene utilizzato altrove al di fuori di questo progetto o se viene considerato come proprio progetto, dovrebbe avere il proprio numero di versione. Probabilmente dovrebbe anche essere spostato da quella soluzione e nella sua. L'unica ragione per cui menziono questo è che ho visto numerose occasioni in cui le persone hanno un assemblaggio usato in un paio di altri posti, ma principalmente in un posto e cercano di mantenere la versione corretta. È una cattiva idea farlo. Penso che il principio di responsabilità unica si applichi anche a livello di soluzione / progetto.

Per quanto riguarda la numerazione, concordo con Guy Starbuck (major.minor.revision.build). È così che l'ho sempre fatto e ha sempre funzionato bene.

Answer 5

Abbiamo un'app di grandi dimensioni (centinaia di assiemi) con rilasci frequenti (circa 1 al mese). Abbiamo optato per il "dare ad ogni assieme la stessa versione" ma per me è una costante fonte di entusiasmo che gli assemblaggi per la versione 1 siano completamente incompatibili con quelli di un'altra, nonostante il fatto che le interfacce di questi assiemi cambino raramente (se mai).

Se questo è il tuo caso, potresti trarre vantaggio dal controllo delle versioni degli assiemi separatamente - ogni volta che aggiorni l'assembly ti preoccupi solo di aumentare il numero di versione nei casi in cui desideri effettivamente interrompere l'associazione degli assiemi (ad esempio se l'interfaccia cambia, o le modifiche sono altrimenti significative quando si desidera impedire a qualcuno di utilizzare accidentalmente la versione precedente).