Decidere i numeri di versione

Question

Duplica

Come eseguire i numeri di versione?

---

Ciao,

Quindi di recente ho visto che Groovy è stato rilasciato alla versione 1.6 e mentre ascoltavano il podcast di Java Posse stavano commentando come ci fosse così tanto contenuto in questa versione che avrebbe dovuto è stata una versione 2.0 .

Mi ha fatto pensare. I numeri di versione sono solo arbitrari? Pensavo che avessero un significato, ma credo di no. È tutto basato solo su pietre miliari e impostare il progetto su progetto?

In che modo il tuo team controlla i numeri di versione e le versioni?

Grazie in anticipo

Answer 1

Distinguere tra il versioning per il marketing e il versioning per uso tecnico.

Per il marketing , la risposta è: " Qualunque cosa tu voglia che i tuoi clienti pensino. " In tal caso, una "nuova versione principale" dovrebbe probabilmente essere accompagnato da un numero di versione principale.

Inoltre, tieni presente che i clienti attenti esiteranno a utilizzare "maggiore" nuove versioni fino a quando non è trascorso il tempo e l'hanno provato in un ambiente di test. Una "modifica di costruzione" la versione è percepita come correzione di bug e altre cose minori che non richiedono molto processo per l'installazione.

Per uso tecnico , la risposta è: " Qualunque informazione tu voglia codificare per gli sviluppatori. " Non esiste un modo corretto per farlo; dipende dai tuoi obiettivi.

Forse un " major " versione significa "cambiamenti significativi che potrebbero significare molti nuovi bug." Forse un nuovo "build" il numero accade su ogni singola compilazione. Forse i tag di costruzione notturni per data sono la tua versione. Puoi basarlo su tempo, cicli di Scrum, pietre miliari, caratteristiche, qualunque cosa!

Answer 2

Sono molto arbitrari. A molte persone piace avere qualcosa di simile

[major].[minor].[release].[revision]

come schema di versioning, ma sono stato anche in aziende che si sono rifiutate di rilasciare un prodotto con marchio 1.0 perché uno dei VP non voleva. Anche il marketing può influenzare questo.

Una buona domanda da porre per aumentare la versione principale può essere:

Se si trattasse di un prodotto a pagamento, i clienti pagherebbero per passare a questa versione più recente?

In tal caso, potrebbe essere utile aumentare il numero maggiore.

Answer 3

MajorRelease.MinorRelease.Hotfix

Answer 4

I numeri di versione sono arbitrari, ma ci sono alcune regole per il pollice (credo). Modifiche o correzioni di bug molto piccole aumentano normalmente di 0.0.1, ovvero V1 diventa V1.0.1. Piccole modifiche alla funzionalità aumentano di 0.1.0, ovvero V1.0.1 diventa V1.1.0. Le principali modifiche o riscritture ottengono un aumento di 1.0.0, ovvero a V2.

Detto questo, molte aziende sembrano tentare di convincere i clienti che qualcosa di importante è aumentato di 1.0.0 quando cambiamenti simili sono stati 0.1.0. Inoltre, alcune aziende che fanno affidamento su contratti di supporto distribuiranno gratuitamente gli aggiornamenti 0.1.0, ma addebiteranno gli aggiornamenti 1.0.0.

Inoltre, IIRC, alcuni progetti tendono a significare build sperimentali con versioni dispari e build stabili come pure, (quindi V3 è pericoloso, V4 è stabile).

Answer 5

Nel caso di una libreria, il numero di versione indica il livello di compatibilità tra due versioni e quindi la difficoltà di un aggiornamento.

Una versione con correzione di bug deve preservare la compatibilità binaria, di origine e di serializzazione.

Le versioni minori significano cose diverse per progetti diversi, ma di solito non hanno bisogno di preservare la compatibilità dei sorgenti.

I numeri di versione principali possono interrompere tutte e tre le forme.

Ho scritto di più sulla logica qui .