Controllo dei numeri di versione negli sprint [chiuso]

Penso che parte della sfida inizi con la tua affermazione di:

Where a Major version is implemented whenever there are breaking changes

E sono abbastanza sicuro che intendi "rompere i cambiamenti" nel senso di cambiamenti significativi dell'API; modifiche alla comunicazione client / server; protocollo, ecc. "Big Stuff" ^(TM) in altre parole.

Ma il problema è che non si tratta solo di rompere i cambiamenti che contano, ma qualsiasi cambiamento significativo che conta. "Significativo" varia da applicazione a applicazione, motivo per cui è difficile essere specifici su ciò che si qualifica come significativo. La modifica del numero maggiore dovrebbe essere un annuncio informale agli utenti finali che:

• Qualcosa di grande è diverso
• Dovrebbero prepararsi o essere consapevoli che questo probabilmente non sarà un aggiornamento banale

Quindi ecco alcuni dei motivi comuni che ho visto per aggiornare il numero maggiore:

• Il marketing (o lo sviluppo) lo ha fatto.
• È stata introdotta una nuova funzionalità di grande novità, nuova di zecca. O un sacco di questi.
• Lo schema del database subì cambiamenti significativi. Spesso questo costringerà un aggiornamento per gli utenti finali.
• Modifiche al protocollo. Ciò può includere modifiche significative tra il browser e il server web o tra il client e il server.
• La stabilità dell'applicazione è notevolmente migliorata (o peggiorata) e si desidera modificare la versione principale per informare o avvisare gli utenti della modifica.
• È trascorso un certo periodo di tempo specifico - potrebbe essere X mesi, anni, qualunque sia.
• Il prodotto è ora conforme ad alcuni standard esterni o comunque a processi di revisione.
• L'applicazione è stata biforcata.
• Sono state apportate modifiche significative alle librerie di supporto o alle librerie che potrebbero essere utilizzate.

In generale, vuoi essere in grado di dire perché hai incrementato il valore maggiore. Questo è dove costruire un "elevator pitch" per giustificare l'incremento può essere utile. E proprio come un elevator pitch che usi per venderti, questa è una breve affermazione che riassume ciò che era abbastanza grande da meritare il cambiamento.

Alcune ulteriori considerazioni sul versioning ...

1. Prima di tutto, non necessario aggiornare il valore Major su base regolare. Potrebbe non avere senso se tutto ciò che viene fornito è un sacco di piccoli oggetti.

2. Se ritieni di essere "a corto di spazio" con i valori degli altri numeri, prendi in considerazione:

   • Utilizza valori esadecimali (base 16) o un'altra base invece dei soli valori decimali (base 10).
   • Utilizza due o più cifre all'interno di ciascun valore. Ad esempio, avresti M.mm.rr.bbb .

Se l'utente del tuo software non è in grado di aggiornare la nuova versione e usarlo senza ulteriori passaggi di migrazione manuale (dati, configurazione, interfacce e simili), questo è un strong indicatore per aumentare la versione principale.

Qualunque cosa tu stia usando internamente, esternamente avrai ancora un ciclo di rilascio simile a cascata.
Che si tratti di una "versione di rilascio", "di rilascio alla produzione", "versione di consegna del cliente" o qualsiasi altra cosa, sarà il prodotto combinato di una serie di sprint e cicli interni più brevi.

Ecco dove arrivano i numeri di alto livello.

Quindi avresti un numero per build notturno (che potrebbe essere eccessivo), un numero per sprint, un numero per consegna a vendite / consegna, e poi hanno messo qualche bella etichetta / numero approvato dal marketing su di esso che è spesso completamente estraneo a qualsiasi cosa usato internamente.