Meilleures pratiques pour étiqueter les versions de jeux?

21

Quelqu'un sait-il s'il existe une meilleure pratique pour l'étiquetage des versions de jeux?

Je ne sais pas s'il existe un nom standard autre que le versioning, mais ce que je veux dire est essentiellement:

  • 1.0
  • 1.1
  • 1.2
  • 1.3.1 beta
clifford.duke
la source

Réponses:

18

Il n'y a pas de norme, mais vous devez le faire d'une manière qui vous convient et qui contient toutes les informations dont vous pourriez avoir besoin pour suivre cette construction. J'ai travaillé pour une entreprise qui l'a essentiellement ventilé comme ceci:

[Numéro de build majeur]. [Numéro de build mineur]. [Révision]. [Package]

ie Version: 1.0.15.2

  • Numéro de build majeur : cela indique un jalon majeur dans le jeu, incrémentez-le lorsque vous passez de la version bêta à la version, de la version aux mises à jour majeures.

  • Numéro de build mineur : utilisé pour les mises à jour de fonctionnalités, les grandes corrections de bugs, etc.

  • Révision : modifications mineures sur les fonctionnalités existantes, petites corrections de bugs, etc.

  • Package : votre code reste le même, les modifications de la bibliothèque externe ou la mise à jour du fichier d'actif.

Les modifications combinées passent au changement le plus significatif. Par exemple, si vous incrémentez le numéro de build mineur, la révision et le package sont tous les deux réinitialisés à 0.

Même si les catégories sont définies, il existe toujours une ambiguïté quant au type de fonctionnalités qui se croisent réellement entre une révision et un numéro de version mineur. C'est à vous. Si vous faites des listes des fonctionnalités qui devront être implémentées avant chaque incrément, vous aurez également un plan à suivre, mais à la fin, c'est à vous de décider ce qui rentre dans chaque catégorie.

MichaelHouse
la source
1
C'est une information géniale, partout où je l'ai regardée, elle ne parlait que des numéros de construction majeurs et mineurs sans aucune explication réelle de ce qui se trouve dans chacun d'eux.
clifford.duke
semver.org
Kzqai
10

Stack Overflow a une grande discussion à ce sujet appelée Comment faire des numéros de version , qui fait référence au Guide de style de version .

Sommaire:

  • Version MAJEURE lorsque vous apportez des modifications d'API incompatibles
  • Version MINEURE lorsque vous ajoutez des fonctionnalités d'une manière rétrocompatible
  • Version PATCH lorsque vous effectuez des corrections de bogues rétrocompatibles
  • Des étiquettes supplémentaires pour les métadonnées de pré-version et de génération sont disponibles en tant qu'extensions au format MAJOR.MINOR.PATCH
Jovan
la source
6

Pour autant que je sache, il n'y a pas de norme pour cela. La pratique variera selon les entreprises, les équipes et les projets: il n'y a pas de meilleure pratique. La chose la plus importante n'est pas la convention proprement dite, mais le fait que tout le monde s'y tient.

Cela dit, le schéma que vous avez mentionné est assez courant pour les jeux sortis. 1.0 sera typiquement le maître d'or, et les correctifs commenceront à partir de là: 1.1, 1.2 ... Il est également utilisé dans les versions client pré-version telles que les bêtas privées ou ouvertes.

Pour les jeux en développement, j'ai rarement vu ce système utilisé. Il est beaucoup plus courant de faire référence à une construction par son ID de changement atomique (par exemple le numéro de liste de modifications Perforce). Cela est particulièrement utile pour un projet de taille moyenne où tout (code et ressources) est stocké sur le même référentiel et une intégration continue est en place. Dans ce cas, avoir à la fois un numéro de modification atomique et un numéro de version est redondant et sujet aux erreurs. Certaines versions seront promues à un jalon après QA: alpha, bêta, version candidate et étiquetées comme telles.

Pour les grands projets, le concept simple de "version jeu" ne s'applique plus. Vous aurez plusieurs plates-formes, SKU, langues, mode solo, mode multi-joueurs, etc. La gestion des versions devient alors un travail à temps plein (parfois appelé gestionnaire de données - c'est la terminologie d'Ubisoft, probablement appelée différemment ailleurs) , le schéma d'étiquetage est alors beaucoup plus complexe et très dépendant du jeu réellement réalisé.

Laurent Couvidou
la source
wow, cela devient un travail en soi? J'ai toujours pensé que les responsables de chaque département géreraient leur propre versioning.
clifford.duke
2
@ChaoticLoki Vous avez besoin d'une bonne coordination entre les services pour vous assurer, par exemple, que les concepteurs de niveaux travaillent sur le dernier exécutable stable. Ou que les programmeurs peuvent trouver qui a foiré une variable dans le texte localisé (comme dans: "Le traducteur italien a corrigé la boîte de dialogue X, a accidentellement cassé le texte du tutoriel Y en même temps, mais nous ne pouvons pas revenir à l'ancienne version parce que l'exe n'est pas pas compatible. Arghhh! Aide? "). Etc. Dans une grande équipe, vous avez besoin de quelqu'un pour s'occuper de tout cela. C'est en fait l'un des emplois les plus difficiles de l'industrie.
Laurent Couvidou