Data come numero di versione del software

Gli sviluppatori di software in genere non usano la data come numero di versione, sebbene il formato AAAAMMGG (o le sue variazioni) sembri abbastanza solido da poter essere utilizzato. C'è qualcosa di sbagliato in questo schema? O si applica solo a "tipi" di software limitati (come le produzioni interne)?

Questo è qualcosa che dovrete dare un'occhiata da un paio di angolazioni diverse in quanto è necessario tenere conto delle esigenze degli utenti e delle esigenze del software e degli sviluppatori.

In generale, i tuoi clienti non si preoccuperanno molto di quale sarà il numero di versione del software, purché sappiano che stanno eseguendo qualcosa di più recente (ovvero il Prodotto 2012 è più nuovo del Prodotto 2010) e che lo sanno è aggiornato se esistono patch che possono essere distribuite (ad es. Prodotto 2012, Aggiornamento 10). In quanto tale, dal punto di vista del marchio del cliente, tendo a preferire una versione denominata (ad esempio Windows XP, Windows Vista) seguita da un rigoroso numero progressivo di patch che possono essere installate dagli utenti.

Detto questo, la scrittura di software che controlla le cose facili per l'utente tende a rendere il codice sotto il cofano molto più difficile da scrivere. Quindi tendo a preferire lo Major.Minorschema di versione semplice se non altro perché puoi fare un semplice confronto tra numeri per verificare che qualcosa sia aggiornato come nel seguente:

// Check to see if we can handle the file version
if (this.Version < fileVersion) {
   throw new UnsupportedFileException("The file version is " + fileVersion.toString() + " which is not supported");
}
// Do stuff ...

Per dirlo in un po 'di contesto, tuttavia, in genere non mi interessa quanto sia grande il numero minore (ovvero 1,1024) che consente al sistema di cui sopra di continuare a funzionare correttamente. Generalmente i numeri di revisione sono solo di interesse per lo sviluppo interno e in realtà non li ho nemmeno visti influenzare cose che vanno ben oltre il semplice dare alle cose un numero aggiuntivo di cui tenere traccia.

Tuttavia, i due schemi precedenti non si applicano solo agli ambienti in cui viene utilizzata la distribuzione continua (ovvero Stack Exchange) che è dove tendo a preferire una sorta di data seguita da un numero di revisione come sembra essere utilizzato nello Stack Stack siti. Il ragionamento di questo è che le versioni cambieranno troppo spesso nell'ambiente di distribuzione continua e potresti avere più versioni del codice che salgono nello stesso giorno, il che giustifica il numero di revisione e la data corrente è buona come qualsiasi per interrompere le cose ancora di più. In teoria, puoi semplicemente usare il numero di revisione per tutto, ma l'uso della data corrente ti consente di tenere traccia delle principali tappe interne che potrebbero rendere le cose un po 'più facili da discutere.

Il problema con l'utilizzo di una data è che le specifiche sono scritte rispetto ai numeri di conteggio anziché a una data alla scadenza.

"Questa funzionalità dovrebbe essere nella versione 1. L'altra funzionalità dovrebbe essere nella versione 2."

Non è possibile fare riferimento a una data nelle specifiche, poiché la data di rilascio potrebbe non essere rilevata.

Se non si dispone di un processo così formale che necessita di diverse versioni identificate in anticipo, l'utilizzo delle date va bene; non è necessario aggiungere un altro numero nel mix.

È improbabile che i numeri di versione contengano date, poiché il loro contesto è collegato alle specifiche. È probabile che i
numeri di build contengano date, poiché il loro contesto è collegato a quando ha avuto luogo la build.

Sebbene questo approccio abbia vantaggi come descritto, ci sono alcuni svantaggi se si utilizza la data come numero di versione:

• Le versioni basate sulla data sono piatte. Con v2.1.3 è possibile visualizzare il numero di versione, il numero della sotto-versione e il numero della sotto-versione secondaria. Con 20110119 puoi vedere solo quando è stato scritto. È possibile raggruppare le versioni di data-base per mese, ma ancora non si direbbe nulla. Potresti avere diversi mesi lenti di correzione di piccoli bug e poi due settimane di codifica pesante con conseguente rilascio importante. Le date non lo dicono, lo fanno i numeri di versione normale.

• Se hai davvero bisogno di cambiare la versione su base giornaliera e possibilmente il numero di versione, ciò può indicare che non hai un corretto processo di rilascio, ma invece tutti cambiano selvaggiamente roba e la promuovono ai server di produzione ogni volta che vogliono. In tal caso, hai un problema con il processo e l'utilizzo di schemi di numeri di versione diversi non risolverà il problema.

Le versioni vengono spesso utilizzate per comunicare informazioni su quanto è diversa una versione particolare del software dalla precedente. Quindi, ad esempio, se si aggiorna da 1.0 a 2.0 di Acme, si tratta di un aggiornamento importante, in teoria che porta grandi cambiamenti.

Un aggiornamento da 1.0 a 1.1, d'altra parte, è un aggiornamento minore e in teoria porta lievi modifiche incrementali e correzioni di bug.

Questo sarebbe difficile da rappresentare in un formato data, anche se potresti usare una miscela. Ad esempio, v1.0.YYYY.MMDD

Senza ripetere buone idee da altre risposte, ho in mente un problema che non è stato ancora affrontato.

Se ti capita di fare un fork, tra una versione precedente per la compatibilità con le versioni precedenti e una nuova versione per una modernizzazione incompatibile, non puoi distinguerli tramite i numeri di versione.

Ad esempio il kernel Linux è stato biforcato intorno all'anno 2000 nel vecchio ramo 2.4.x, che probabilmente è ancora supportato oggi e conta come 2.4.199, mentre la nuova versione è stata 2.6 per molti, molti anni, ed è 2.6.32 per i sistemi più vecchi, ma 3.2 per i kernel più recenti.

Se disponi di documentazione sulle tue versioni, raddoppierai le informazioni e dirai alle persone che la versione 20120109 è arrivata nel 2012 all'01 / 09. Mh. Ma cosa succede, se c'è un rilevamento di bug dell'ultimo momento e un rilascio è ritardato di una settimana, ma la documentazione, in cui viene menzionato il nome, è già pronta, forse stampata, le informazioni sulla stampa sono fuori e così via. Ora hai una discrepanza che è problematica, se la versione 20120109 è arrivata al 2012/01/13.

In SQL, la domanda se gli ID debbano contenere informazioni semantiche è stata spesso discussa e il risultato è sempre: evitatelo come l'inferno! Stai creando una dipendenza non necessaria. Non può essere di beneficio.

Ubuntu con il suo schema 04/10 ha avuto il suo problema nel 2006, quando la versione 6.04 è stata ritardata ed è diventata 6.06. Nel 3000 ci sarà presto il prossimo problema! :)

Esistono molti pacchetti software che utilizzano effettivamente la data come versione. Mi viene in mente Ubuntu, dove la loro versione è YY.MM. E i numeri di build per i prodotti Microsoft Office sono anche una codifica della data di build. Jeff Atwood ha scritto un post sul blog di Coding Horror sulla numerazione delle versioni , incluso questo consiglio:

Se possibile, utilizzare date semplici anziché numeri di versione, in particolare nei nomi pubblici dei prodotti. E se devi assolutamente, positivamente usare i numeri di versione internamente, rendili comunque delle date: assicurati di codificare la data della build da qualche parte nel tuo numero di versione.

Secondo me, non importa finché sei coerente e sei in grado di passare da un numero di versione di build (qualunque esso sia) e ricordare tutti gli artefatti che sono entrati in quella build dal tuo sistema di controllo della versione. Gli utenti in genere non si preoccupano affatto delle informazioni sulla versione, ma piuttosto della funzionalità fornita dal sistema. Le informazioni sulla versione hanno un valore reale solo per gli sviluppatori.

Usa il controllo delle versioni semantico: in questo modo puoi avere un'idea del tipo di modifiche apportate tra le versioni senza dover ispezionare il codice stesso: http://semver.org/

L'uso dei numeri di versione è un modo per mostrare quanto GRANDE sia la modifica

Ad esempio, 2.4.3 può significare che la versione 2 è la principale modifica all'intero sistema. .4 è un aggiornamento minore. e l'ultimo .3 è una piccola correzione di bug a quella versione. In questo modo è facilmente riconoscibile quanto è cambiato tra ogni versione.

Detto questo, vedo ancora che molte persone usano le date o i numeri di revisione SCM come numeri di versione, purché tu abbia un modo per rintracciare le note di rilascio e la documentazione di supporto di ciò che era nell'ambito di quella versione, non c'è alcun problema reale.

Alcune buone risposte qui già, ma vorrei sottolineare un caso in cui l'uso delle date ha perfettamente senso: piccole librerie o frammenti di codice in cui è probabile che il codice venga aggiornato frequentemente ma in minuscole parti senza una singola versione che differiscono drammaticamente dalla precedente uno.

In altre parole, sto parlando di situazioni in cui non esiste un vero "numero di versione" ma fondamentalmente una sorta di dump del repository quasi giornaliero.

Quando mi imbatto in questo genere di cose, di solito accolgo con favore la scelta in quanto è più utile per me sapere che sto usando uno script / lib relativamente attuale piuttosto che una versione specifica.

Le date come numero di versione sono buone per il marketing. Se le persone utilizzano "Windows NT 5.0", potrebbero non rendersi conto che è obsoleto. Ma se le persone usano ancora "Windows 2000", sapranno immediatamente che si tratta di un sistema operativo di 12 anni e saranno incoraggiati ad aggiornarlo.

Tuttavia, rende più difficile distinguere tra aggiornamenti "principali" e "minori".

Problema con l'utilizzo di Date come numeri di versione

Le risposte qui sono buone, ma non ho visto nessuno rispondere a questa preoccupazione utilizzando le date: l'utente non può determinare con quale frequenza sono state apportate modifiche.

Quello che sto cercando di dire è che posso dire che Windows 3.1 e Windows 7 sono molto distanti ... e forse sono incompatibili. Windows 95 e Windows 2000 non dicono altro che l'anno in cui è stato introdotto il prodotto.

Ad esempio, con Python, so che la versione 2.7.2 si è evoluta dalla 2.4.6. Se guardo oltre, vedo che la versione 2.4.6 è stata rilasciata il 19 dicembre 2008; e quella versione 2.7.2 è stata rilasciata l'11 giugno 2011. Da questo, posso formulare un'opinione sulla stabilità (cioè sulla frequenza di rilascio) di un prodotto.

Se invece Python avesse usato le date di rilascio, non saprei come collegare questi prodotti. Ne deriverebbe un'ulteriore confusione, perché Python 3.1.4 è stato rilasciato anche l'11 giugno 2011 (lo stesso di Python 2.7.2).

In breve, non penso che, di per sé, il versioning delle date sia prezioso.

Non mi piace questa idea, per ragioni già descritte da altri. Usa lo schema major.minor.bugfix: c'è un motivo per cui la maggior parte delle persone lo fa in questo modo.

Ma qualunque cosa tu faccia: scegli uno schema di denominazione delle versioni e atteniti ad esso . Non farlo come Windows, dove cambiano lo schema ad ogni versione. E non farlo come Android, dove ogni versione ha un numero di versione API (8), un numero di versione destinato al marketing (2.2) e un nome stupido (Froyo).

Data come versione

Se il tuo prodotto non viene venduto, usare semplicemente la data va bene e probabilmente è utile. Se lo vendi e gli aggiornamenti ai clienti vogliono acquistare un modello con un set specifico di funzionalità. È molto più facile venderli su un aggiornamento se questo modello ha un nome chiaro, non importa davvero cosa sia, ma per esempio nessuno compra davvero la Ford Car del 20 gennaio 2012 vogliono il Modello Kia qualunque cosa. Lo stesso vale per il software. Dare un nome e una versione del modello duro significa che ha caratteristiche diverse da una precedente. Per me solo un appuntamento non lo fa, dice che l'ho fatto allora, non potrebbe avere nuove funzionalità.

Schema che usiamo

Non ho affermato che il nostro sistema crea un marchio chiaro come sopra. Ora usiamo uno schema in quattro parti. Un numero di versione, stato, data e checksum.

1200_GLD_120120_F0D1

Questo può aggravarsi ma ci consente di avere diverse versioni della build per la versione 1200 che i nostri ingegneri possono usare e che ci differenziamo tra loro per data. Lo stato dice alle persone se si tratta di una versione di test interna, di una build di patch per il cliente o di una versione Gold. Il checksum è nuovo, consente a un ingegnere o un cliente di verificare che abbia effettivamente scaricato quello corretto dalla nostra distribuzione.

Quindi potremmo avere una sequenza di

1200_TST_120110_EF45
1200_GLD_120120_F0D1
1201_FIX_120125_123E
1201_TST_120130_31A5
1201_TST_120131_FDFD

Normalmente ci riferiamo solo ai numeri di versione principali per il cliente, ad esempio "12", ma un cliente riceverà l'ultima versione in oro di 12, ovvero 1200_GLD_120120_F0D1 a meno che non necessiti della correzione.

Supponiamo che alcuni clienti utilizzino la versione due del tuo prodotto e alcuni abbiano eseguito l'aggiornamento alla versione tre e che l'aggiornamento non sia una decisione presa alla leggera.

Supponiamo che l'ultima versione della versione due sia la 2.3.2 e la versione tre sia alla 3.0.3. Ora trovi una vulnerabilità che deve assolutamente essere riparata, quindi rilasci 2.3.3 e 3.0.4 lo stesso giorno. Riesci a vedere come la data di uscita è totalmente irrilevante? Potresti aver smesso di funzionare sulla versione due nel 2013 e da allora ha rilasciato solo alcune correzioni di bug essenziali. La data è irrilevante rispetto al numero di versione.

Penso che funzioni alla grande. Lo uso per alcuni software interni (yyyy.mm.dd) e per alcuni software open source che ho rilasciato.

Potrebbe non funzionare in tutti i casi.

Tecnicamente non può usare la data per il numero di versione, ma potrebbe mostrare il numero di data per il cliente. Ad esempio, macOS 16.7.23 --- significa che: 23/7/2016

Penso che la tecnologia non sia il problema, il problema è che come ci si sente? Se usi un numero di data che potrebbe rendere il software vivo, vivo, proprio come un uomo con il numero di compleanno. Ogni anno in cui stiamo crescendo, lo stesso del software continua a crescere.

Il numero dell'edificio appare come la macchina, la macchina, non viva, non vivente.