Quando devo incrementare il numero di versione?

Non ho imparato la programmazione a scuola e non lavoro come sviluppatore (professionale), quindi molte nozioni di base non sono abbastanza chiare per me. Questa domanda cerca di chiarire uno di essi.

Ora supponiamo che io abbia dei problemi #1, #2e #3nel mio Tracker dei problemi che sono impostati per essere corretti / migliorati per la versione 1.0.0e che l'ultima versione (stabile) è 0.9.0.

Quando devo passare alla versione 1.0.0? Quando a) è chiuso solo uno dei problemi sopra elencati oppure b) quando tutti i problemi relativi alla versione 1.0sono chiusi?

Qual è il modo giusto per farlo? E nel modo giusto , intendo quello che è attualmente utilizzato nel settore.

Posso dirti come lo faccio al lavoro.

Disponiamo di un server di integrazione continua che crea, verifica, tag e genera un pacchetto con versione. Passiamo alla fase successiva se la precedente ha successo al 100%.

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

• Ogni build di successo che non presenta correzioni di bug o miglioramenti delle funzionalità incrementa il numero di build.
• Ogni build di successo con una correzione di bug completata o il miglioramento delle funzionalità aumenta la versione secondaria. Questo viene rilevato automaticamente dalla presenza di un messaggio di commit utilizzando un formato particolare. Questo messaggio di commit viene anche automaticamente inserito nei progetti ChangeLog.
• Ogni incremento della versione principale viene eseguito manualmente quando vengono apportate modifiche non retrocompatibili, riscrivibili da zero o altri motivi fatti caso per caso.

I numeri di versione sono rilevanti solo per le versioni , poiché consentono agli utenti esterni di identificare una build specifica del software. Se sei solo impegnato nello sviluppo e non nel rilasciare ogni correzione singolarmente, non preoccuparti di aumentare il numero di versione per ogni correzione. Non è rilevante per gli utenti esterni e fa perdere tempo con la contabilità delle versioni extra.

Per le applicazioni Web distribuite in modo continuo, tendiamo a costruire numeri di build utilizzando symver in primo piano e un numero di build tailing, ovvero: 2.5.3.4328 in cui 4328 proviene dal sistema di integrazione continua. L'aspettativa generale è che i numeri cambino con passaggi deliberati ma che il numero di build sia il vero ID univoco.

Quello 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 davvero bisogno del controllo delle versioni pubblico (il controllo delle versioni non pubbliche è il tuo VCS), aggiungi la parola chiave " SNAPSHOT " alla fine della versione. Alcuni sistemi, specialmente nella gestione delle dipendenze, trattano le istantanee in modo diverso dalle versioni rilasciate in quanto confrontano la data di modifica delle istantanee anziché il numero di versione. Quindi se hai avuto una v. 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, scaricherà quello 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.

Quando devo incrementare alla versione 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 cosa importante, perché la percezione pubblica sarà che stai passando da un prodotto beta a una versione ufficiale.

(Presumo che qui sia 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 quello è fondamentalmente lo standard del settore.

La nostra azienda è passata dalla versione 2.x alla 3.0 e ha organizzato una grande festa, creato molti buzz e per questo ha ottenuto un bel po 'di nuovi clienti. A parte alcuni aggiornamenti dell'interfaccia, le differenze tra le versioni erano piuttosto lievi.