Ci sono degli svantaggi nella strategia di versione Major.Minor.YMDD.Build?

Naviga le tue risposte
1

Sto cercando di trovare una buona strategia di versione per soddisfare le nostre esigenze specifiche. Abbiamo proposto di stabilirci e volevo porre la domanda per vedere se l'esperienza di qualcuno suggerisse di evitarlo o di alterarlo in qualsiasi modo.

Ecco la nostra proposta:

Le versioni vengono rilasciate in questo formato: MAJOR.MINOR.YMDD.BN. Qui è scomposto:

  • MAJOR & MINOR sono tipici; aumenteremo MINOR quando sentiamo il codice e le nuove serie di funzioni lo giustificano; una volta ogni pochi mesi molto probabilmente. MAJOR aumenterà di ~ annualmente.
  • YMDD: Y sarà l'ultima cifra dell'anno corrente, quindi "1" per il 2011, "2" per il 2012, ecc. Un mese non imbottito verrà utilizzato per mantenere il numero più piccolo (9 invece di 09 per esempio). DD è ovviamente il giorno, riempito con uno zero per i giorni minori di 10.
  • BN: BN è il numero di build e aumenta di un'unità ogni volta che apportiamo una modifica a un ramo del codice rappresentato dalla build, ad esempio:

Se dovessi creare una build oggi, la nostra versione sarebbe la versione 5.0.1707.1. Rilascio al QA oggi e tra 3 giorni il QA rileva che una modifica ha interrotto la funzionalità di salvataggio su una pagina. Invece di modificare il nostro attuale codice di sviluppo, tornerei al codice che ho usato per creare la versione 5.0.1707.1, apportare la correzione lì, quindi aumentare la parte BN della versione e quindi re-release 5.0.1707.2 indietro al QA. In breve, ogni volta che viene apportata una modifica a una versione ramificata che non è il ramo dev attivo, dovremmo utilizzare il numero di versione originale e aumentare solo la parte BN (anche se la modifica è avvenuta 3 giorni, 3 settimane o 3 mesi da la versione iniziale di quella versione).

Ogni volta che creiamo una nuova versione dal nostro ramo Active Dev, avremo una nuova versione basata sul M / D del rilascio usando la strategia delineata. Lo facciamo una volta ogni 2-3 settimane.

Ci sono buchi o problemi con questo? Se sì, quali sono?

Grazie

Modifica

Per chiarire un punto che non sono uscito molto bene - Oct / Nov / Dec sarà di due cifre, è solo l'anno che non sarà. Quindi 9 per settembre, 10 per ottobre, 11 per novembre, ecc.

    
posta Chu 07.07.2011 - 16:40
fonte

4 risposte

9

YMDD: Y will be the last digit of the current year, so "1" for 2011, "2" for 2012, etc. A non-padded month will be used to keep the number smaller (9 instead of 09 for example).

Vedo un grosso problema con questo: rompe l'ordine naturale delle tue versioni. Cioè 5.0.11001.1 (pubblicato il 1 ° ottobre) arriverà prima di 5.0.1930.1 (pubblicato il 30 settembre).

A parte questo, per me, la leggibilità è più importante del salvataggio di alcune cifre, quindi preferirei andare con un formato data YYYMMDD completo. Oppure, in alternativa, un terzo numero di versione (di rilascio), in ogni caso, la data di rilascio può sempre essere fatta risalire allo SCM.

    
risposta data 07.07.2011 - 17:13
fonte
8

Normalmente non mi preoccuperei della parte della data se hai major.minor.build: questo porta solo alla confusione dell'utente. Puoi sempre ottenere la data dal numero di build e fintanto che il numero di build aumenta monotonicamente, a chi importa?

L'opinione varia a seconda che tu debba reimpostare il numero di build su una nuova versione principale. Generalmente, il numero di build viene ripristinato con un nuovo progetto. Se la Versione 2 è un nuovo progetto o solo una nuova versione dipende dalle tue cose interne.

    
risposta data 07.07.2011 - 17:10
fonte
2

Gli unici che riesco a vedere:

  • L'uso dell'ultima cifra dell'anno potrebbe essere un problema se il tuo prodotto vive più di 10 anni.

  • Usare una sola cifra per il mese: come fai a distinguere tra gennaio che sarebbe "1" sotto il tuo schema e novembre che probabilmente sarebbe anche "1"?

Fondamentalmente, la tua parte "YMDD" è ambigua e alquanto priva di significato. "1101" potrebbe essere "2011-01-01" o "2021-11-01. Mi piacerebbe correggerlo cambiando in" YYMMDD ", rimuove l'ambiguità ed è anche un numero strettamente crescente (finché non si passa al successivo secolo). Sì, sono due caratteri in più (anche se potresti salvarne uno se hai fatto il mese in esadecimale, quindi novembre sarebbe "B") ma quando un numero di build è 5.0.1707.1 vs. 5.0.110707.1, in realtà non è così male. So che nel contesto del resto del numero di build, non è così male, ma comunque, hai chiesto ...

    
risposta data 07.07.2011 - 17:10
fonte
1

L'ora del PC potrebbe non essere sincronizzata con lo stesso server orario. Se più di un PC crea il programma in pochi minuti, il numero di versione potrebbe non rappresentare l'ordine di creazione, il che porta a confusione.

    
risposta data 04.11.2012 - 08:19
fonte

Leggi altre domande sui tag

Nel calcolare quanti giorni tra 2 date, dovresti includere entrambe le date nel conteggio, o nessuna delle due, o 1? Un errore logico è sempre causato dalla riga di codice per il primo stato del programma che è sbagliato? [chiuso]