Le migliori pratiche per l'etichettatura delle versioni del gioco?

Qualcuno sa se esiste una best practice per l'etichettatura delle versioni del gioco.

Non sono sicuro che esista un nome standard diverso dal controllo delle versioni, ma ciò che intendo è fondamentalmente:

• 1.0
• 1.1
• 1.2
• 1.3.1 beta

Non esiste uno standard, ma dovresti farlo in un modo che abbia senso per te e contenga tutte le informazioni di cui potresti aver bisogno per tracciare quella build. Ho lavorato per un'azienda che essenzialmente lo ha suddiviso in questo modo:

[Numero di build principale]. [Numero di build minore]. [Revisione]. [Pacchetto]

cioè Versione: 1.0.15.2

• Numero di build principale : indica un importante traguardo nel gioco, incrementandolo quando si passa dalla versione beta alla versione, dalla versione ai principali aggiornamenti.

• Numero di build minore : utilizzato per gli aggiornamenti delle funzionalità, correzioni di errori di grandi dimensioni ecc.

• Revisione : piccole modifiche su funzionalità esistenti, piccole correzioni di errori, ecc.

• Pacchetto : il codice rimane lo stesso, modifiche alla libreria esterna o aggiornamento del file delle risorse.

Le modifiche combinate passano al cambiamento più significativo. Ad esempio, se si sta incrementando il numero di build minore, la revisione e il pacchetto vengono entrambi reimpostati su 0.

Anche se le categorie sono definite, c'è ancora ambiguità per quale tipo di funzionalità attraversi effettivamente tra una revisione e un numero di build minore. Tocca a voi. Se fai elenchi delle funzionalità che dovranno essere implementate prima di ogni incremento, avrai anche un piano da seguire, ma alla fine è la tua decisione su ciò che rientra in ciascuna categoria.

Stack Overflow ha una grande discussione su questo chiamato How To Do Version Numbers , che fa riferimento alla Guida allo stile di versione .

Sommario:

• Versione MAJOR quando si apportano modifiche API incompatibili
• Versione MINORE quando si aggiunge funzionalità in modo compatibile con le versioni precedenti
• Versione PATCH quando si apportano correzioni di bug compatibili con le versioni precedenti
• Ulteriori etichette per i metadati pre-release e build sono disponibili come estensioni al formato MAJOR.MINOR.PATCH

Per quanto ne so, non esiste uno standard per questo. La pratica varierà a seconda delle aziende, dei team e dei progetti: non esiste una best practice. La cosa più importante non è la convenzione vera e propria, ma il fatto che tutti si attengono ad essa.

Detto questo, lo schema che hai citato è abbastanza comune per i giochi rilasciati. 1.0 sarà in genere il gold master e le patch inizieranno da lì: 1.1, 1.2 ... È anche usato nelle versioni pre-release dei clienti come beta private o open.

Per i giochi in sviluppo raramente ho visto questo sistema usato. È molto più comune fare riferimento a una build tramite il suo ID di cambiamento atomico (ad esempio il numero della lista delle modifiche di Perforce). Ciò è particolarmente utile per un progetto di media scala in cui tutto (codice e risorse) è archiviato nello stesso repository ed è presente un'integrazione continua. In questo caso, avere sia un numero di cambiamento atomico che un numero di versione è ridondante e soggetto a errori. Alcune build verranno promosse a una pietra miliare dopo il QA: alpha, beta, release candidate ed etichettate come tali.

Per i grandi progetti, il semplice concetto di "versione del gioco" non si applica più. Avrai diverse piattaforme, SKU, lingue, modalità single player, modalità multi-player, ecc. La gestione delle versioni diventa quindi un lavoro a tempo pieno (a volte chiamato data manager - questa è la terminologia di Ubisoft, probabilmente chiamata diversamente altrove) , lo schema di etichettatura è quindi molto più complesso e fortemente dipendente dal gioco reale in corso di realizzazione.