Quando dovrei incrementare il numero di versione?

Posso dirti come lo faccio al lavoro.

Abbiamo un server di integrazione continuo che crea, collauda, etichetta ed emette un pacchetto con versione. Passiamo alla fase successiva solo se il precedente è riuscito a% 100.

La nostra versione è la seguente: < Versione principale >. < Versione secondaria >. < Numero build >

• Ogni build di successo che non ha una correzione di bug o funzionalità migliorata incrementa il numero di build.
• Ogni build di successo con una correzione di bug completata o un miglioramento delle funzionalità incrementa la versione secondaria. Questo viene rilevato automaticamente dalla presenza di un messaggio di commit utilizzando un particolare formato. Anche questo messaggio di commit viene automaticamente inserito nel progetto ChangeLog.
• Ogni incremento della versione principale viene eseguito manualmente quando non abbiamo modifiche compatibili con le versioni precedenti, riscriviamo da zero o altri motivi fatti caso per caso.

I numeri di versione sono rilevanti solo per releases , poiché rappresentano un modo per gli utenti esterni di identificare una build specifica del tuo software. Se sei solo impegnato nello sviluppo e non rilasciando ciascuna correzione individualmente, non preoccuparti di incrementare il numero di versione per ogni correzione. Non è rilevante per gli utenti esterni e spreca il tuo tempo con la contabilità delle versioni extra.

Per le applicazioni Web continuamente utilizzate, tendiamo a costruire numeri di build usando symver in primo piano e un numero di build tailing, ovvero: 2.5.3.4328 in cui 4328 deriva dal sistema di integrazione continua. L'aspettativa generale è che i numeri cambiano con passi intenzionali ma che il numero di build è il vero ID univoco.

Ciò che sembra fare qui è catturare il giorno della distribuzione e il relativo numero di build svn:

        <div id="svnrev">
            rev 2013.10.21.1078
        </div>

Per quello che vale.

Le altre risposte sono già ottime, quindi le aggiungerò solo sopra. Se il tuo software non viene rilasciato e non hai realmente bisogno di versioning pubblico (il controllo di versione non pubblico è il tuo VCS), aggiungi la parola chiave " SNAPSHOT " alla fine della tua versione. Alcuni sistemi, in particolare nella gestione delle dipendenze, trattano gli snapshot in modo diverso rispetto alle versioni rilasciate in quanto confrontano la data di modifica delle istantanee anziché il numero di versione. Quindi, se avevi una versione di 1.0.0-SNAPSHOT dalle 8:00 in un repository di pacchetti e un downloader di dipendenze locali ha la stessa versione dalle 7:00, scarica il file aggiornato dal repository.

Come detto sopra, il tuo versioning privato è fornito dal tuo sistema di controllo della versione (git, svn ecc.).

C'è abbastanza da dire sulla teoria del versioning, ecco un altro punto di vista.

When should I increment to version 1.0.0 ?

Concentrerò la mia risposta sul cambiamento del numero di versione principale.

La mia risposta è: fondamentalmente quando sei pronto per questo. Passare da 0,9 a 1,0 è una grande cosa, perché la percezione pubblica sarà che stai passando da un prodotto beta a un rilascio ufficiale.

(assumerò qui è un prodotto commerciale di un'azienda)

Alcune domande prima di passare da 0.9 a 1.0.

La tua organizzazione ha il tempo di informare tutti i tuoi attuali clienti. Organizzare una festa. Ricevi molte richieste di supporto. Un account manager per vendere il tuo prodotto? Ecc. Ecc.

Sì, vedo il controllo delle versioni come uno strumento di marketing e, se ti guardi intorno, vedi che questo è fondamentalmente lo standard del settore.

La nostra azienda è passata dalla versione 2.x alla 3.0 e ha avuto una grande festa, ha creato molto entusiasmo e, a causa di ciò, ha avuto parecchi nuovi clienti. A parte alcuni aggiornamenti di interfaccia, le differenze tra le versioni erano piuttosto ridotte.