Best practice: versione del software [chiusa]

211

Esistono linee guida o best practice standard su come rendere divertente un software sviluppato nel tempo libero, ma che verrà comunque utilizzato da alcune persone? Penso che sia necessario versioni di tale software in modo che tu ne sappia con la versione uno di cui stai parlando (ad esempio per la correzione di bug, il supporto e così via).

Ma da dove comincio il controllo delle versioni? 0.0.0? o 0,0? E poi come incrementare i numeri? major release.minor change? e nessuno dovrebbe impegnarsi in un sistema di controllo versione essere un'altra versione? o è solo per le versioni utilizzate in modo produttivo?

versioning

— RoflcoptrException
fonte

Cosa fa lo strumento di controllo del codice sorgente? È necessario utilizzare uno. Quale stai usando?

— S.Lott

Sono un po 'in ritardo ... ma un duplicato di stackoverflow.com/questions/615227/how-to-do-version-numbers

— derivazione

semver.org

— Dave Gregory,

@DaveGregory ha una risposta non basata sull'opinione alla domanda. Quel link semver.org descrive dettagliatamente una versione semantica delle versioni. Lo stesso schema è comunemente usato dalla maggior parte dei progetti Google, incluso Android. Inoltre, in Tom Preston-Werner possiamo trovare la voce più credibile di qualsiasi altro su questo argomento.

— Rahul Murmuria,

125

Dovresti iniziare con la versione 1, a meno che tu non sappia che la prima versione che "rilasci" è in qualche modo incompleta.

Per quanto riguarda il modo in cui incrementare le versioni, dipende da te, ma usa la numerazione di build maggiore, minore come guida.

Non è necessario avere tutte le versioni che commetti per il controllo del codice sorgente come un'altra versione: presto avrai un numero di versione molto grande. Devi solo aumentare il numero di versione (in qualche modo) quando rilasci una nuova versione nel mondo esterno.

Quindi, se fai una grande modifica, passa dalla versione 1.0.0.0 alla versione 2.0.0.0 (ad esempio hai cambiato da WinForms a WPF). Se apporti una modifica più piccola, passa da 1.0.0.0 a 1.1.0.0 (hai aggiunto il supporto per i file png). Se apporti una modifica minore, passa da 1.0.0.0 a 1.0.1.0 (hai corretto alcuni bug).

Se vuoi davvero ottenere dettagli usa il numero finale come numero di build che aumenterebbe per ogni checkin / commit (ma penso che vada troppo lontano).

— ChrisF
fonte

Ho una domanda sulla tua risposta: se sto lavorando con la versione 1.0.0.0 e sto implementando una modifica minore, più piccola o grande e voglio anche usare il numero di build. Su quale numero di versione devo aggiungere la versione build? Immagina, sto passando dalla 1.0.0.0 alla 1.0.1.0. Su quale numero devo inserire il numero di build? E, nella versione finale, avrà anche il numero di build sul suo numero di versione (1.0.1.234)?

— VansFannel,

@VansFannel, mi aspetto che il numero di build si reimposti su 0 ogni volta che si salta un numero superiore.

— Jeffrey Kemp

@JeffreyKemp Sì, penso di sì. Ma al lavoro usiamo il numero del giorno dell'anno e non mi piace.

— VansFannel

Yuck, non mi piacerebbe neanche questo :(

— Jeffrey Kemp

Va inoltre notato che le modifiche nelle versioni principali in genere non sono compatibili con le versioni precedenti. Gli incrementi nella versione secondaria sono retrocompatibili con la versione principale. Il passaggio da un'implementazione di MySQL con codifica rigida a un'implementazione generica potrebbe essere una versione principale a causa delle dimensioni della modifica, ma potrebbe anche essere considerata una modifica di funzionalità (minore) perché rimane compatibile con le versioni precedenti.

— Acqua calda sanitaria