Cosa usare come versione iniziale? [chiuso]


122

Di solito inizio i miei progetti con una versione 1.0.0. Non appena ho delle cose insieme, la rilascio come 1.0.0 e passo con la 1.1.0.

Tuttavia, questo porta alla versione 1.0.0 utilizzabile ma non esattamente completa della maggior parte delle cose che scrivo. Quindi aggiungo funzionalità e ottengo una versione decente da qualche parte intorno alla 1.6.0. Molti progetti iniziano con la versione 0.1.0, che sarà utilizzabile quanto la mia 1.0.0.

Cosa suggeriresti di fare? Inizia con 1.0.0 o 0.1.0?

L'ultimo numero è solo per i rilasci di bugfix. Puoi pensare al mio 1.0.0 come 1.0 e 0.1.0 come 0.1 è più facile per te.


1
Ho appena scoperto il "controllo delle versioni semantico" ( semver.org ), è più o meno quello che voglio fare. Tuttavia, non sto creando API e si tratta di API, quindi il consiglio 1.0.0 non si applica realmente.
Noarth


Risposte:


-24

Il mio controllo delle versioni è guidato dalla configurazione. Voglio che sostituisca le versioni precedenti, quindi continuo ad aumentarlo a salti che hanno senso per me.

A volte, tuttavia, il controllo delle versioni è guidato dal cliente, soprattutto se rilasci il codice al pubblico.

Se è la tua chiamata, fai quello che funziona meglio per te. Ho avuto alcuni problemi con le versioni precedenti alla 1.0, quindi comincio con quello.


1
Non spieghi davvero nulla nella tua risposta. Non dici che tipo di problemi hai avuto, quindi possiamo discuterne. Non spieghi quando e perché le versioni sono guidate dal cliente, il che non è comunque il caso di OP. E non spieghi come e perché il controllo delle versioni sia guidato dalla configurazione. Cosa intendi con questo, in un modo che sia importante per la risposta? Una risposta ben definita dovrebbe includere contro e pro di ogni decisione, hai incluso solo vaghi ragionamenti :).
Eksapsy

225

Lo standard Semantic Versioning 2.0.0 dice:

La cosa più semplice da fare è avviare la versione di sviluppo iniziale alla 0.1.0 e quindi incrementare la versione secondaria per ogni versione successiva.

Va bene passare da 0.3.0 direttamente a 1.0.0. Va anche perfettamente bene essere a 0.23.0. Iniziare a 0.4.0 è alquanto sconsigliabile in quanto suggerisce che ci sono state versioni pubblicate precedenti.

Inoltre, nota che 0.y.zè tenuto da parte per una rapida iterazione, in modo che lo sviluppo iniziale (e quindi molte modifiche sostanziali) non ti lasci a qualcosa di sciocco come 142.6.0. Invece di eseguire il bump della versione principale, eseguire il bump della versione secondaria su ogni modifica sostanziale fino al rilascio della 1.0.0:

La versione principale zero (0.yz) è per lo sviluppo iniziale. Tutto può cambiare in qualsiasi momento. L'API pubblica non dovrebbe essere considerata stabile.


Questa DEVE essere la risposta accettata. Mai vista una risposta con 16 voti negativi come risposta accettata
Nader Ghanbari il

C'è una trappola se usi npm. Se inizi con 0, il segno di caret "^" in package.json si comporterà in modo diverso. docs.npmjs.com/misc/semver#caret-ranges-123-025-004 Puoi utilizzare 0.x invece di ^ 0. nel pacchetto json per questo scenario. Pertanto, 1.x è un po 'più facile da avviare e utilizzare.
Sam

9

Il numero di versione dipende interamente da te. Fai ciò che ha senso per te e sii coerente. Nessuno dice che devi iniziare da 0, o 0,0, o 1,0 o 1,1.

I grandi programmatori hanno effettivamente utilizzato il sistema di numerazione delle versioni come scherzi locali. Esempi (Wikipedia):

Dalla versione 3, TeX ha utilizzato un sistema di numerazione delle versioni idiosincratico, dove gli aggiornamenti sono stati indicati aggiungendo una cifra in più alla fine del decimale, in modo che il numero di versione si avvicini asintoticamente a π. Questo è un riflesso del fatto che TeX è ora molto stabile e sono previsti solo aggiornamenti minori. La versione corrente di TeX è 3.1415926; è stato aggiornato l'ultima volta nel marzo 2008

Per METAFONT:

Metafont ha un sistema di versioning simile a quello di TeX, dove il numero si avvicina asintoticamente a e ad ogni revisione.

Infine, non proprio un numero di versione, ma altrettanto interessante, è che l'offerta pubblica iniziale (IPO) di Google è stata depositata presso la SEC per aver raccolto $ 2.718.281.828 (si noti che e ~ 2.718 281 828).

Il punto è: non sentire di dover seguire la folla. Sii creativo e coerente.


6

Penso che qui entrino in gioco diversi fattori. Deve essere preso in considerazione l'impatto psicologico / di marketing del numero di versione (numero di versione aumentato spesso => ​​più $$$, le persone non vogliono acquistare una versione beta 0.99, ecc.). I numeri di versione "logica" possono aiutare quando si lavora in un team enorme.

E mi piace il modo Linux di avere numeri dispari per le versioni instabili e numeri pari per quella stabile.


1

Quando ottengo la mia prima versione utilizzabile pronta ma non completa di funzionalità, normalmente cerco di giudicare a che punto è verso una versione completa di funzionalità, quindi ad esempio se il mio primo utilizzabile è al 33% di funzionalità complete, creo il numero di versione 0.3.0 o simile. Quindi, man mano che mi muovo verso le versioni complete di funzionalità, vengono assegnati numeri in modo simile.

Ma una volta che si passa alle funzionalità precedenti, è necessario modificare il completo controllo delle versioni


3
Ciò in qualche modo implica che puoi arrivare solo fino a 0.9.0, ma conosco molti progetti che vanno avanti come 0.25.0.
Noarth

Tendo a usare l'ultima serie di cifre per modifiche incrementali minori e correzioni di bug e mantengo la serie centrale di cifre per modifiche abbastanza importanti, quindi non ho mai la necessità di inserire due cifre per i numeri centrali
Tristan

1

Quando si scelgono i numeri di versione per un npmpacchetto, tenere presente che per le dipendenze elencate negli package.json intervalli semver non funzioneranno al di sotto della v1.0.0. Questo è,

"dependencies": {
    "my-package": "^0.5"
}

è equivalente a

"dependencies": {
    "my-package": "0.5"
}

Se vuoi essere in grado di usare gli intervalli di semver o vuoi che altre persone li usino, potresti iniziare con 1.0.0


Interessante. Hai maggiori informazioni sul perché (o dove) gli intervalli Semver non funzionano sotto 1.0.0? Poiché ci sono parecchi pacchetti che utilizzano 0.0.xnel registro npm .
Remi

Non so perché la gente di npm abbia preso questa decisione, o dove sia stata presa nel sistema npm / cosa dovrebbe cambiare per supportare intervalli di semver per versioni inferiori a 1. Sarei interessato a saperlo anch'io!
henry

3
Hanno preso quella decisione perché ^significa "compatibile con la versione" . Maggiori dettagli qui . In semver, 0.y.zè pensato per lo sviluppo iniziale e qualsiasi modifica yo zpuò essere incompatibile all'indietro. Nel tuo esempio, ^0.5 := 0.5 := 0.5.xquindi è un intervallo. Se l'intervallo di caret non funziona per te 0.y.znell'intervallo, puoi utilizzare gli intervalli di comparatore, hypen, x e tilde, oltre agli intervalli di caret.
Dosentmatter

0

In genere, il controllo delle versioni ha un significato per il programmatore. L'aumento del numero maggiore potrebbe indicare grandi modifiche che impediscono la compatibilità con le versioni precedenti. Altri numeri nel numero di versione potrebbero indicare miglioramenti delle funzionalità più piccoli o correzioni di bug.

Se sei preoccupato che la versione 0.6.5 abbia un suono incompleto, potresti volerla commercializzare con la versione 1.0. Il numero della versione di marketing non deve necessariamente corrispondere al numero della versione interna. Il numero di versione di Windows 7, ad esempio, è 6.1.

La mia preferenza personale è iniziare da 0.1.0 e andare da lì.


0

Dipende dal progetto. Per semplici strumenti da riga di comando, di solito inizio intorno a 0.9 [.0] poiché prendo in considerazione di rilasciarli o comprimerli solo quando sono vicini al completamento (o comunque pronti per il beta test). Progetti più complicati iniziano intorno a 0.1 [.0] e alcuni non vedono nemmeno 1.0. Considero 1.0 una versione di rilascio (o almeno una beta o una release candidate testata localmente) e pianifico di conseguenza.

Con i progetti di squadra, chi mette il primo tag della versione può decidere :).


0

0.1.0 è ciò con cui inizio e da lì salgo. Questo è ciò che ho adattato per Xploration By Adrian, anche se nei miei primi anni ero molto sporadico e usavo 1.0.0, 0.0.1 e pochi altri. Ma consiglio di iniziare da 0.1.0 e di andare da lì.

Per Semver, riserva aec in abc per A. La tua prima versione ufficiale e C. Correzioni di bug e patch. Questo perché una versione principale generalmente interrompe il codice precedente. E le patch risolvono semplicemente i bug. Questa è tutta una preferenza personale, 0.99.0 non significa che devi andare a 1.0.0, ecc. Ne ho visti alcuni che vanno fino a 0.218.42.


-1

I numeri di versione dovrebbero avere significato per te come Arrieta ha correttamente commentato in precedenza.

Forse seguendo qualcosa del tipo: La prima # è la versione del sindaco, la seconda # è la stessa versione del sindaco con alcune funzionalità aggiunte e la terza # è la stessa versione del sindaco, con le stesse funzionalità ma con bug corretti o modifiche piccole (ma abbastanza significative) aggiunte.

1.3.2 => 1 ° rilascio, con più funzionalità e alcuni bug corretti.

Tuttavia, per gli utenti finali, alcuni sono abituati a grandi numeri per le versioni finali.

Ad esempio: Corel 8, per 8.0.0, 8.0.1, 8.2.2, ecc. Corel 9, per 9.0.0 ... ecc.

E principalmente riguarda strategie di marketing come: Corel X5 invece di Corel 15.0.2, ad esempio.

Direi che dipende se il numero di versione è per te o per il client.


-4

inizia con 0.0.0 e prosegui da lì.


4
Ciò significa che faresti effettivamente una versione 0.0.0? Inizio con il primo numero che pubblicherò.
Noarth

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.