C'è qualche ragione per utilizzare uno stile di versioning rispetto all'altro per gli assembly .NET ????major.minor.build.revision versioning style vs year.month.day.whatever stile versioning
Mi piacerebbe sapere se ci sono vantaggi/svantaggi nell'utilizzo di uno stile diverso dal gusto.
Il vantaggio del tempo è che si ottiene sia un numero di versione crescente e codificare il timestamp.
Il vantaggio di utilizzare numeri più tradizionali è che è più facile da capire per le persone. Sappiamo tutti approssimativamente cosa significa "v2.1", per esempio.
In generale, suggerisco di utilizzare il tempo perché le informazioni aggiunte sono utili. Il vantaggio degli altri numeri è solo per il marketing, e per quello puoi farlo comunque.
Ad esempio, perché non hanno entrambi, a "v2.1.20090214". Ora hai il marketing nella sezione major.minor e nella sezione "build".
Ho appena lasciato AssemblyVersion in "1.0. *" E rimosso qualsiasi AssemblyFileVersion.
Posso quindi incrementare i numeri di versione Major e Minor come sembra appropriato e lasciare che la build e la revisione di base DateTime di default siano impostate automaticamente.
A meno che non si disponga di strumenti di compilazione alternativi che controllano il numero di build e di revisione in base ad altri schemi, non vedo alcun vantaggio reale impostarli manualmente.
Sto facendo esattamente la stessa cosa. –
Uso alcuni script di build che aggiornano la mia revisione in base alla revisione SVN. Ciò rende banale il tracciamento di una dll sul codice sorgente che lo ha creato.
Il tempo è più complicato; devi iniziare a cercare nel riquadro della cronologia, dove la maggior parte degli strumenti di controllo del codice sorgente ha una funzione di "revisione".
Perché scegliere? Puoi utilizzare un formato come Major.Minor.YYMMDD.Revision e ottenere il meglio da entrambi i mondi.
Modifica Come indicato nei commenti a volte l'intervallo di ciascun campo è limitato. In tal caso è possibile utilizzare Major.Minor.YMMDD.Revision.
Speriamo che cambi la versione secondaria almeno ogni 10 anni!
correggimi se ho torto, ma secondo MSDN su "http://msdn.microsoft.com/en-us/library/system.reflection.assemblyversionattribute.aspx" ogni componente deve essere un numero compreso tra 0 e 65535. YYMMDD sarebbe troppo grande. "Major.Minor.YYYY.MMDD" si adatterebbe ma è impaziente :-( – angrifel
Uno svantaggio della numerazione delle versioni basata su date è la percezione negativa del software precedente.
Anche se lo uso comunque perché si adatta molto bene ai miei progetti.
Non sempre uno svantaggio.Questa percezione negativa può essere utilizzata per vendere la tua nuova versione. –
Utilizzando data/ora ha un altro (oltre a quelli già detto in altre risposte qui) svantaggio:
se sei team di sviluppo si sviluppa su diversi fusi orari, non sarai mai sicuro che uno dei due versioni costruite a distanza di un'ora è la più recente. A meno che non si esegua anche la modifica del fuso orario o si imposti la data/ora in ad es. GMT.
Il vantaggio dell'utilizzo dello schema major.minor.revision è la semantica.C'è un metodo per aggiornare ognuno di questi numeri:
La modifica del numero principale indica che la nuova versione non è compatibile con quella precedente e qualsiasi dipendente della versione precedente richiederà modifiche al codice per l'aggiornamento al nuovo pacchetto.
Modifica numero minore significa che la nuova versione è retrocompatibile con la versione precedente ma presenta miglioramenti significativi rispetto alla versione precedente.
Il numero di revisione viene aggiornato ogni volta che viene applicata una correzione alla build in modo tale da non apportare modifiche di compatibilità o introdurre funzionalità più nuove.
Mentre si specificano le dipendenze, si può dire che si dipende da foo-1.0.0 - foo-1.99.999, e si ha la certezza che non si finirà con un aggiornamento del pacchetto che interrompe l'applicazione.
Se si inizia con una versione secondaria minore di una dipendenza, ad esempio foo-1.4.22, è necessario specificare la dipendenza come foo-1.4.22 - foo-1.99.999, in modo da non finire installazione di una versione precedente alla 1.4.x, che potrebbe avere qualche funzionalità/miglioramento mancante.
Se si usa una data come numero di versione, per misericordia usare il formato AAAAMMGG. È l'unico che chiunque può leggere senza ambiguità e ha il vantaggio di ordinare lessicalmente nell'ordine corretto. – Evan
(Per i parrocchiani tra noi, alcuni paesi scrivono le loro date nel formato MM-GG-AAAA e la maggior parte del resto della saggia parola li scrive nel formato GG-MM-AAAA o AAAA-MM-GG.) – Evan
Nota che su Win32 (e quindi su .NET), i numeri di versione hanno un limite di 16 bit per componente, quindi 20090214 come un componente non è possibile. –