Gli sviluppatori di software in genere non usano la data come numero di versione, sebbene il formato YYYYMMDD (o le sue varianti) sia abbastanza solido da essere utilizzato. C'è qualcosa di sbagliato in questo schema? Oppure si applica solo ai "tipi" di software limitati (come le produzioni interne)?
Questo è qualcosa che dovrai dare un'occhiata da un paio di punti di vista diversi, in base alle esigenze degli utenti e alle esigenze del software e degli sviluppatori.
In generale, ai tuoi clienti non interesserà molto il numero di versione del software finché sapranno di eseguire qualcosa di più recente (ad esempio, Product 2012 è più recente di Product 2010) e sanno che è aggiornato se ci sono patch che possono essere implementate (es. Product 2012, Update 10). Pertanto, dal punto di vista del marchio del cliente, preferisco le versioni con nome (ad esempio Windows XP, Windows Vista) seguite da un numero sequenziale di patch che possono essere installate dagli utenti.
Ciò detto, scrivere software che controlli le cose che sono facili per l'utente tende a rendere il codice molto più difficile da scrivere. Quindi tendo a preferire il semplice schema di versione Major.Minor se solo perché puoi fare un semplice confronto dei numeri per verificare se qualcosa è 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 mettere questo in un po 'di contesto, in generale, non mi interessa quanto grande diventa il numero minore (cioè 1.1024) che consente al sistema di cui sopra di continuare a funzionare correttamente. Generalmente i numeri di revisione interessano solo lo sviluppo interno e in realtà non li ho nemmeno visti influenzare cose che vanno oltre il semplice dare un numero aggiuntivo per tenerne traccia.
Tuttavia, i suddetti due schemi non si applicano solo agli ambienti in cui viene utilizzata la distribuzione continua (ad es. Stack Exchange), che è dove preferisco una sorta di data seguita da un numero di revisione come sembra essere usato su i siti Stack Exchange. Il ragionamento per questo è che le versioni cambieranno troppo spesso nell'ambiente di distribuzione continua e potresti avere più versioni del codice in aumento nello stesso giorno che giustifica il numero di revisione e la data corrente è buona quanto quella necessaria per rompere le cose ancora di più. In teoria si potrebbe semplicemente usare il numero di revisione per tutto ma l'uso della data corrente consente di tenere traccia delle principali tappe interne che potrebbero rendere le cose più facili da discutere.
Il problema con l'utilizzo di una data è che le specifiche vengono scritte rispetto ai numeri di conteggio anziché a una data in cui è prevista.
"This piece of functionality is due to be in release 1. The other piece of functionality is due to be in release 2."
Non è possibile fare riferimento a una data nelle specifiche, poiché la data di rilascio potrebbe non essere rispettata.
Se non si dispone di un tale processo formale che necessita di versioni diverse identificate in anticipo, l'uso delle date va bene; non è necessario aggiungere un altro numero nel mix.
I numeri di versione non sono probabilmente contenenti date, dal momento che il loro contesto è collegato alle specifiche. I numeri di build possono contenere date, poiché il loro contesto è collegato a quando la build è avvenuta.
Sebbene questo approccio abbia dei vantaggi, come descritto, ci sono alcuni svantaggi se si usa la data come numero di versione:
Le versioni basate su data sono piatte. Con la versione 2.1.3 puoi vedere il numero di versione, il numero di versione secondaria e il numero di sotto-versione secondaria. Con 20110119 puoi vedere solo quando è stato scritto. potresti raggruppare le tue versioni basate su date per mese, ma non ti direbbe nulla. Potresti avere diversi mesi lenti di piccoli bug fixing e poi due settimane di codifica pesante che hanno portato a una major release. Le date non ti dicono che, i numeri di versione regolari fanno.
Se hai davvero bisogno di cambiare la versione su base giornaliera e possibilmente rilasciare il numero, può indicare che non hai un processo di rilascio appropriato, ma invece tutti cambiano e lo diffondono ai server di produzione ogni volta che loro vogliono. In tal caso, si è verificato un problema con il processo e l'utilizzo di uno schema del numero di versione diverso non lo risolverà.
Le versioni vengono spesso utilizzate per trasmettere informazioni su come una versione particolare del software è diversa da quella precedente. Ad esempio, se si aggiorna da 1.0 a 2.0 di Acme, questo è un aggiornamento importante, in teoria con importanti cambiamenti.
Un aggiornamento da 1.0 a 1.1, d'altra parte, è un aggiornamento minore e in teoria comporta modifiche minori e incrementali e correzioni di bug.
Questo sarebbe difficile da rappresentare in un formato data, anche se potresti usare una mistura. Ad esempio, v1.0.YYYY.MMDD
Senza ripetere buone idee da altre risposte, ho un problema in mente 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 informerai le persone che la versione 20120109 è arrivata nel 2012 all'01 / 09. Mh. Ma cosa succede se viene rilevata una segnalazione di bug dell'ultimo momento e una release viene posticipata di una settimana, ma la documentazione, dove viene citato 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 questione se gli ID debbano contenere informazioni semantiche è stata spesso discussa, e il risultato è sempre: evitatelo come un matto! 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. Nell'anno 3000 ci sarà presto il prossimo problema! :)
Ci sono molti pacchetti software che usano 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 del data di costruzione. Jeff Atwood ha scritto un post sul blog di Coding Horror sulla numerazione delle versioni , compresa questa raccomandazione:
Whenever possible, use simple dates instead of version numbers, particularly in the public names of products. And if you absolutely, positively must use version numbers internally, make them dates anyway: be sure to encode the date of the build somewhere in your version number.
A mio parere, non importa fino a quando si è coerenti e si è in grado di passare da un numero di versione build (qualunque esso sia) e richiamare tutti gli artefatti che sono stati generati dal sistema di controllo della versione. Gli utenti di solito non si preoccupano delle informazioni sulla versione, ma piuttosto della funzionalità fornita dal sistema. Le informazioni sul controllo delle versioni sono di reale valore per gli sviluppatori.
L'uso dei numeri di versione è un modo per mostrare quanto è GRANDE la modifica
Ad esempio 2.4.3 potrebbe significare che la versione 2 è la modifica principale dell'intero sistema. .4 è un aggiornamento minore. e l'ultimo .3 è una piccola correzione di bug per quella versione. In questo modo è facilmente riconoscibile quanto è cambiato tra ogni versione.
Detto questo, vedo ancora che molte persone usano le date oi numeri di revisione SCM come numeri di versione a patto che tu abbia un modo per rintracciare le note di rilascio e la documentazione di ciò che era in-scope per quella release non ci sono problemi reali .
Alcune buone risposte già qui, 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 piccoli bit senza una singola versione che differisce in modo drammatico alla precedente.
In altre parole, sto parlando di situazioni in cui non esiste un vero "numero di versione" ma fondamentalmente una sorta di dump di repository quasi quotidiano.
Quando mi imbatto in questo genere di cose, di solito accolgo la scelta, poiché è più utile per me sapere che sto usando uno script / lib piuttosto recente 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 è un sistema operativo di 12 anni e saranno incoraggiati ad eseguire l'aggiornamento.
Tuttavia, rende più difficile distinguere tra aggiornamenti "principali" e "minori".
Questa idea non mi piace, per ragioni già descritte da altri. Usa lo schema major.minor.bugfix - c'è un motivo per cui molte persone lo fanno in questo modo.
Ma qualunque cosa tu faccia: scegli uno schema di denominazione della versione e tienilo . 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 che è destinato al marketing (2.2) e un nome stupido (Froyo).
Problema con l'utilizzo delle date come numeri di versione
Le risposte qui sono buone, ma non ho visto nessuno affrontare questo problema con l'utilizzo delle date: l'utente non può determinare la frequenza con cui 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 mi dicono altro che l'anno in cui è stato introdotto il prodotto.
Ad esempio, con Python, so che la versione 2.7.2 si è evoluta dal 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 posso sapere come potrebbero essere collegati questi prodotti. Ne risulterebbe un'ulteriore confusione, poiché anche Python 3.1.4 è stato rilasciato l'11 giugno 2011 (lo stesso di Python 2.7.2).
In breve, non penso che, di per sé, la versione delle date sia preziosa.
Data come versione
Se il tuo prodotto non è venduto, è sufficiente usare la data e probabilmente utile. Se lo vendi e si aggiorna 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 quello che è ma, ad esempio, nessuno acquista davvero la Ford Car del 20 gennaio 2012, vogliono il modello Kia. Lo stesso vale per il software. Dare un nome e una versione di un modello duro significa che ha caratteristiche diverse da una versione 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 mai affermato che il nostro sistema, crea un marchio chiaro come sopra. Ora utilizziamo uno schema in quattro parti. Un numero di versione, stato, la data e un checksum.
1200_GLD_120120_F0D1
Questo potrebbe sembrare eccessivo ma ci consente di avere diverse versioni della build per la versione 1200 che i nostri ingegneri possono utilizzare e noi distinguiamo tra loro per data. Lo stato comunica alle persone se si tratta di una versione di test interna, una build di patch cliente o una versione gold. Il checksum è nuovo, consente a un ingegnere o cliente di verificare che in realtà hanno 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
Solitamente ci riferiamo ai numeri di versione principali per il cliente, ad esempio "12", ma un cliente riceverà l'ultima versione gold di 12 ovvero 1200_GLD_120120_F0D1 a meno che non abbiano bisogno della correzione.
Supponiamo che alcuni clienti utilizzino la seconda versione del prodotto e che alcuni siano passati 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 della 3.0.3. Ora trovi una vulnerabilità che deve essere assolutamente risolta, quindi rilasci 2.3.3 e 3.0.4 nello stesso giorno. Riesci a vedere come la data di rilascio è totalmente irrilevante? Potresti aver smesso di lavorare sulla versione due nel 2013 e solo da allora sono state rilasciate 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 il numero della data che potrebbe rendere il software vivo, vivo, proprio come un uomo che ha il suo numero di compleanno. Ogni anno cresciamo, lo stesso che il software continua a crescere.
Il numero dell'edificio assomiglia alla macchina, alla macchina, non vivo, non vivo.
Leggi altre domande sui tag versioning