Cosa usare come versione iniziale? [chiuso]

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.

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.

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.

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.

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.

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

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

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ì.

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.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.

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.

inizia con 0.0.0 e prosegui da lì.

Inizia con 1.1.1 e vai avanti da lì.