Versione incrementale - Durante lo sviluppo? o dopo il rilascio?

6

Ho quello che ritengo sia una domanda in gran parte soggettiva, ma sono interessato a come le persone gestiscono la situazione descritta di seguito. Ci sono molte domande simili sullo scambio di programmatori, ma nessuna che tocchi questo preciso problema sull'opportunità di aggiornare un numero di versione alla versione proposta prima o dopo lo sviluppo (che ho trovato).

Ho un sistema che è attivo, chiamiamolo versione 1.0.x.x sto usando Major.Minor.Build.Revision versioning di stile Microsoft.

Ricevo una richiesta del cliente per alcune nuove funzionalità e decidiamo che questo pacchetto di lavoro sarà la versione 1.1.x.x.

Quando aggiorneresti il tuo numero di versione, in fase di sviluppo? Come inizi a lavorare? o come lo hai finito?

Riesco a vedere due approcci, nessuno dei quali sono al 100% felice.

  1. Incrementa la versione secondaria all'avvio dello sviluppo, facendo in modo che l'eventuale software rilasciato sia probabilmente simile a 1. 1 .5562.12589

  2. Conserva la versione 1.0.xx durante lo sviluppo, portando la versione tested a qualcosa come 1. 0 .5562.12589 e poi quando ho bisogno di aggiornare il version di l'assembly (che dovremmo fare manualmente per una versione maggiore o minore) a 1. 1 .xx in senso stretto quella versione del codice (come avrei dovuto ricostruire per incrementare l'assembly numero) non è stato testato.

Qual è l'approccio preferito qui?

EDIT:

In termini di pro e contro:

Opzione 1.
Pro - La versione rilasciata è già 1.1.xx, quindi il numero minore è accurato e tale build / revisione rappresenta il codice testato
Contro - La versione rilasciata non sarà la versione 1.1.0.0 che, per il cliente o lo sviluppatore, potrebbe sembrare che il lavoro sia stato pubblicato dopo una versione 1.1.0.0, come correzioni di bug. / p>

Opzione 2.
Pro : la versione non raggiunge la versione 1.1.0.0 finché lo sviluppo non è completo & testato. Significa che c'è un netto taglio logico tra il lavoro eseguito sulla versione 1.0.xx stabile e la distribuzione della versione 1.1.0.0 testata.
Contro - La versione deve essere regolata manualmente da 1.0 Da .xx a 1.1.0.0 da qualche parte dopo il test ma prima del rilascio. Potenzialmente incluso codice non testato se qualcuno ha erroneamente controllato nell'area sbagliata.

Al momento non sono sicuro di quale sia il minore dei due mali in quanto riesco a vedere i pro per entrambi, così come gli svantaggi per entrambi. Spero che qualcuno possa aiutarmi a ribaltare l'equilibrio o individuare qualcosa che mi è sfuggito.

    
posta dougajmcdonald 08.04.2015 - 11:53
fonte

2 risposte

6

Se il problema è che il cliente potrebbe pensare che 1.1.2475.54387 significa "qualcosa è cambiato dopo l'1.1" - dimenticalo. Nella mia esperienza, praticamente tutti i clienti o non si preoccupano di ciò che i componenti di ordine inferiore in una versione significano, o loro si preoccupano e capiscono che sono numeri di build e revisioni VC, che per definizione non possono mai essere 0.

Leggermente più generale: guardare bene è un obiettivo valido, ma in un contesto aziendale importa solo ciò che pensa la persona che prende la decisione di acquisto. Queste persone ricadono quasi sempre nella categoria (a) di cui sopra. Non riesco a pensare a nessuno scenario in cui avere un numero di build non incontaminato possa influire negativamente sul successo commerciale di un prodotto.

    
risposta data 08.04.2015 - 12:16
fonte
2

Un grande vantaggio dell'opzione 1 è che non appena il software passa tutti i test unitari e i test di accettazione con la nuova serie di requisiti, è possibile spedirlo.

Se si ritardano l'incremento del numero di versione, sarà necessario eseguire un'altra build con la versione corretta che si desidera spedire. Dopo averlo ricreato tutto, dovresti davvero ripetere tutti i test di nuovo.

    
risposta data 08.04.2015 - 12:39
fonte

Leggi altre domande sui tag