Supponiamo di avere un'applicazione Web con alcune funzioni di base. Voglio pubblicizzarlo. Quindi mi piacerebbe assegnare un numero di versione - qualcosa come 0.0.1. Quello che voglio sapere è che ci sono dei vincoli che dovrebbero applicarsi a quel sistema di numerazione?Nozioni di base sulla numerazione delle versioni?
Spero tu abbia capito la mia domanda, grazie in anticipo.
La maggior parte dei luoghi utilizzare qualcosa di simile:
Maggiore Release.Minor Release.Hot Fix.Build
I suoi numeri di versione sarà simile 1.5.0.15, ecc
È possibile utilizzare qualsiasi forma di numerazione delle versioni desiderata.
Mi raccomando solo di usare qualcosa che abbia senso. La numerazione Major.Minor.Revision è popolare, ma qualsiasi schema di numerazione che si desidera è "valido".
sì, vedere ad esempio MS Windows: 95, 4.0, 98, 2000, XP, Vista, 7 –
@just: Quelli sono "versioning commerciale". Se scavi da qualche parte, troverai la versione ufficiale di sviluppo. –
Questi erano i nomi dei prodotti, non i numeri di versione. –
È possibile utilizzare qualsiasi numero che si desidera nel proprio controllo delle versioni: chi vi costringerà?
Se si desidera che la prima versione sia 0.0.0.0.0.0.0.1, va bene, anche se un po 'sciocco. Se vuoi che la tua prima versione sia 106.3, puoi farlo anche tu, ma è un po 'più ridicolo.
Controlla lo Wikipedia article on Software Versioning per alcune idee provate e vere di schemi di numerazione delle versioni realistici.
Si potrebbe desiderare di iniziare dando un'occhiata all'articolo Software versioning su wikipedia, che fornisce alcune informazioni sulle possibilità che hai ;-)
Potrebbe darti qualche idea su cosa potresti fare nel caso specifico ...
Ho sempre usato (riscrittura). (Funzionalità aggiunta). (Correzione errori).
Ma imposta le tue regole e rendile pubbliche così che i tuoi utenti le capiscano.
Mi piace il fatto che sei riuscito a descrivere major.minor.patch, ma lo hai fatto sostituendo i termini normali con quello che in realtà significano. Molto più facile da capire rapidamente. – Harvey
Ho usato
Major.Minor.Release.Build 1.02.4.15
e anche
Year.Month.Date
2009.12.10
ma tutto ciò che ti permette di monitorare individualmente le versioni funzionerebbe. Finché sei coerente.
Usiamo major.minor.revision.build dove revisione è la revisione SVN e accumulo è il numero di build, che si basa sulla data corrente (in formato yyddd dove YY è l'anno e DDD il numero del giorno, quindi 18001 sarebbe il 1 ° gennaio 2018.)
Avere la revisione SVN è incredibilmente utile e ci ha salvato in più di un'occasione.
Dai uno sguardo allo here.python setuptools ha una specifica molto interessante e chiara per la numerazione delle versioni. Sono sicuro che è possibile ottenere alcuni suggerimenti molto perspicaci da esso.
In base alle mie conoscenze, non esiste ancora un'agenzia governativa che stabilisca come le vostre versioni numerate. Ma non preoccuparti, sono sicuro che arriverà abbastanza presto.
Idem su quelli che suggeriscono la revisione del punto principale. Il mio approccio generale è: le principali modifiche ottengono una nuova versione principale. Ad esempio, se abbiamo aggiunto nuove funzionalità importanti. Piccole modifiche, come aggiunte alcune caratteristiche di comodità o un nuovo rapporto, ottenere una revisione secondaria. Le modifiche alla correzione degli errori più recenti ottengono una revisione.
Eviterei sicuramente di chiamare la prima versione pubblicata "0.l" per ragioni di marketing semplici: i numeri inferiori a 1.0 sembrano una versione preliminare o una versione beta. Ho conosciuto persone che chiamano la loro prima versione 2.3 o alcune semplicemente per far sembrare che sia passato un po 'di tempo a ispirare più sicurezza, anche se questo mi sembra un po' disonesto.
I numeri di versione non sono una specifica concreta nello sviluppo del software.
In altre parole, una squadra può utilizzare 1.0.0.0, altre possono utilizzare 1.0.0 e così via. Non importa.
Basta scegliere qualcosa che funzioni per voi.
In genere major.minor.revision è il metodo più semplice e diretto da utilizzare. Ad esempio, Visual Studio può assegnare automaticamente i numeri di versione, così come altri strumenti. Quindi tutto ciò che è necessario aggiornare è il valore maggiore/minore. I numeri di compilazione/revisione vengono aggiornati automaticamente.
Un sacco di software libero utilizza un sistema a tre punti: X.Y.Z dove
In questo modo la versione 0.28.1 è una versione stabile con una correzione e 2.9.0 una versione alfa con correzioni zero.
Alcune persone si divertono anche a sviluppare i propri schemi. Per esempio. Tex che per ogni versione approssima Pi, con i numeri di versione: 3, 3.1, 3.14, ecc.
+1 per indicare la modifica dispari –
Non importa, purché sia possibile utilizzare il numero di versione per identificare le proprie versioni (ad esempio, aggiungere il controllo del codice sorgente numero di revisione interno del sistema nel numero di versione) o utilizzarlo per contrassegnare le versioni.
Quando si esegue questa operazione, è possibile utilizzare tale numero come terzo componente (o quarto). Sembra confuso se alcuni prodotti saltano dalla versione 1.12345 alla 2.12346, ma il salto da 1.4.12345 a 2.0.12345 è più comune.
A proposito di quale numero per iniziare, voglio solo citare Eric S. Raymond:
Nel mondo closed-source, versione 1.0 significa "Non toccare questo se siete prudenti.", Nel mondo open-source si legge qualcosa di più come 'I sviluppatori sono disposti a scommettere i loro reputazione su questo'
+1 per la fine() – RCIX
Mi pare di ricordare che in passato (parlo Commodore qui.) abbiamo usato una sintassi simile release.version.revision che potrebbe essere aggiunto con la loro correzione e/o costruire, dove fix sarà di norma una lettera attaccata direttamente alla revisione Quindi un numero completo leggerebbe qualcosa come:.
2.1.44a.786
Ma come molti hanno già detto, non importa, non esiste uno standard vero per questo. Usa semplicemente ciò che è più conveniente per te.
cosa ne pensi del software che non è distribuito al pubblico come un codice sorgente webmail? pensi che il numero di build o bug fix sia ancora importante in questo caso?
Durante lo sviluppo di librerie software, I recommend utilizzando il numero di versione per comunicare il livello di compatibilità sorgente e binario tra due rilasci.
Poiché si sta sviluppando un'applicazione Web, è probabilmente sufficiente un numero di versione in due parti. La prima parte è per nuove funzionalità e la seconda è per le correzioni.
Dopo aver letto un sacco di articoli/esegue il QA/FAQ/libri divento a pensare che [MAJOR]. [MINOR]. [REV] è più utile schema di controllo delle versioni per descrivere la compatibilità tra versione del progetto (versioni dello schema per sviluppatore, non per marketing).
PRINCIPALI modifiche è all'indietro incompatibili e richiedono la modifica nome del progetto, percorso dei file, GUID, ecc
MINORI cambiamenti è retrocompatibile. Contrassegna l'introduzione delle nuove funzionalità .
REV per la sicurezza/correzioni di errori. Compatibile con le versioni precedenti e successive.
Questo schema di controllo delle versioni ispirato libtool la semantica di versioning e dagli articoli:
http://www106.pair.com/rhp/parallel.html
NOTA: Consiglio anche fornire build///qualità personalizzati data informazioni come aggiuntivo (build numero, data di costruzione, nome del cliente, qualità di rilascio):
Hello app v2.6.34 per banca nazionale, 2011-05-03, beta, costruire
Ma queste informazioni non è informazioni delle versioni !!
10.50.1600.1
major.minor.build.revision
grandi cambiamenti è all'indietro incompatibili e necessario cambiare il nome del progetto, il percorso di file, GUID, ecc
piccole modifiche è retrocompatibile. Contrassegna l'introduzione di nuove funzionalità.
REV per sicurezza/correzioni di errori. Compatibile con le versioni precedenti e successive.
es. In SQL Server 2008 il numero di versione RTM è 10.00.1600.22 e in SQL Server versione 2012 è 11.00.2100.60
primo campo viene modificato dovute al mutamento di nome del progetto vale a dire 10 e 11
in SQL Server 2008 R2 versione RTM il numero è 10.50.1600.1 e nella versione di SQL Server 2008 è 11.00.1600.22
Il secondo campo è stato modificato a causa dell'introduzione di nuove funzionalità.
terzo campo indicano costruire (con allacciamenti)
Forth campo indica revisione ossia aggiornamenti rapidi applicati ...
Che tipo di applicazione è vero, e quanto spesso pensi che farai gli aggiornamenti? Hai qualche tipo di calendario? Quanti utenti lo userebbero? L'aggiornamento –
dipende dalle funzionalità o dalle versioni di bug risolte. Numero di utenti non è una preoccupazione – coderex
mi dispiace non ho alcun sistema di controllo della versione. Voglio solo avere una conoscenza di base su questo. perché suppongo di resase un sito Web, quindi voglio mantenere il sistema di versione. – coderex