[YYYY]. [MM]. [DD]. [hh] [mm] vs. [maggiore]. [minore]. [revisione] [duplicato]

Perché non combinarli:

[maggiore]. [Minore]. [YyyymmddHHMM]

In questo modo ottieni un modo semplice di mostrare la versione (la funzione disponibile) e inoltre un metodo per vedere quando è stata creata.

Questo metodo consente anche di avere due versioni diverse nel campo (Ver 1 / Ver 2) contemporaneamente.

Scelgo il sistema [major].[minor].[revision] principalmente perché consente agli utenti / clienti / ecc. sapere quanto è grande il cambiamento del nuovo aggiornamento.

Alcuni utenti / clienti / ecc. non vorrei aggiornare ad una nuova versione se è solo un [revision] . Potrebbero voler aspettare una variazione [major] . Una modifica [major] potrebbe essere una modifica dell'interfaccia utente. Una modifica dell'interfaccia utente, non importa quanto piccola, può essere un enorme affare per un utente finale.

Perderai questa capacità con il sistema [YYYY].[MM].[DD].[hh][mm] . Gli utenti / clienti / ecc. non sapremo quanto è grande una modifica a meno che non guardino il log di aggiornamento.

link

In the world of software management there exists a dread place called "dependency hell." The bigger your system grows and the more packages you integrate into your software, the more likely you are to find yourself, one day, in this pit of despair.

In systems with many dependencies, releasing new package versions can quickly become a nightmare. If the dependency specifications are too tight, you are in danger of version lock (the inability to upgrade a package without having to release new versions of every dependent package). If dependencies are specified too loosely, you will inevitably be bitten by version promiscuity (assuming compatibility with more future versions than is reasonable). Dependency hell is where you are when version lock and/or version promiscuity prevent you from easily and safely moving your project forward.

As a solution to this problem, I propose a simple set of rules and requirements that dictate how version numbers are assigned and incremented...

I call this system "Semantic Versioning." Under this scheme, version numbers and the way they change convey meaning about the underlying code and what has been modified from one version to the next.

Il versioning semantico aiuta a impostare e mantenere le aspettative.

[Major]. [Minor]. [Revision]. [Build] Usa la data di rilascio per registrare la data e l'ora e tenerla separata. Includendo il numero di build come parte della versione, puoi sapere esattamente cosa è in produzione, testare, ecc senza dover pensare o cercare date e orari e check-out, ecc.

Dipende dal tipo di progetto.

Il controllo delle versioni con un timestamp generalmente funziona bene per le applicazioni Web, dove esiste solo una copia live del codice distribuito.

Il controllo delle versioni con Major.Minor.Revision generalmente funziona meglio quando devi gestire diverse versioni simultaneamente distribuite.

La numerazione e il controllo delle versioni non devono essere uguali. È possibile utilizzare [YYYY]. [MM]. [DD]. [Hh] [mm] per il sistema di build, basta dare al ramo di rilascio un nome di [Major]. [Minor]. [Revision] quando lo si crea.

major vs minor vs revision non è soggettivo, è piuttosto semplice.

revisions sono correzioni di bug o modifiche,

minor sono aggiunte e modifiche che non interrompono le API o il comportamento esistenti,

major interrompe l'API o aggiunge funzionalità che cambiano il funzionamento della versione esistente.

Questi sono casi empirici e non soggettivi.

Personalmente suggerirei [major]. [minor]. [revision]. [YYYYMMDD] Non sono esattamente sicuro del motivo per cui hai bisogno dell'ora e del minuto in cui è stato creato: $

Mi piace [major]. [minor]. [build], dove il numero maggiore viene incrementato quando viene eseguito un aggiornamento incompatibile maggiore, minore viene incrementato con ogni release (service pack, hotfix, rilascio di sicurezza) e il numero di build viene incrementato con ogni build. Non vedo il punto di avere più di 3 numeri nel numero di versione. Perché vorresti saltare dei numeri o avere paura dei grandi numeri?

Dipende molto dal tuo software e dalle piattaforme per cui lo stai pubblicando. Un paio di casi in cui potresti preferire un tradizionale [major]. [Minor]. [Revision] sistema di versioning sono:

1. Se vendi software termoretraibile, la tua politica di licenza potrebbe essere legata a versioni principali / secondarie. Ad esempio, potresti vendere MyApp v2.0.0507 a un cliente per $ 99 e includere due anni di upgrade gratuiti a qualsiasi versione futura di MyApp v2.X.X. È un po 'più complicato da fare con le versioni di timestamp.

2. In .NET, il CLR (o fusione) utilizza le versioni dell'assieme per determinare quale versione di un assembly condiviso si deve associare. Ad esempio, se è appena stato rilasciato MyLib.dll v2.0.0507.0 e è necessario rilasciare una patch di sicurezza, si aumenterebbero i numeri [build] o [revision] (ad es .: v2.0.0519.0 o v2.0.0507.1) quindi il CLR avrebbe (per impostazione predefinita) associare la build dell'applicazione esistente con MyLib.dll v2.0.XX alla nuova versione del service pack. Se aumenti i campi [maggiore] o [minore], il CLR dovrebbe assumere che si tratta di una nuova versione e di non associarvi le vecchie applicazioni.