¿Alguien sabe si hay una mejor práctica para etiquetar versiones de juegos?
No estoy seguro de si hay un nombre estándar para él que no sea versionar, pero lo que quiero decir es básicamente:
- 1.0
- 1.1
- 1,2
- 1.3.1 beta
¿Alguien sabe si hay una mejor práctica para etiquetar versiones de juegos?
No estoy seguro de si hay un nombre estándar para él que no sea versionar, pero lo que quiero decir es básicamente:
Respuestas:
No existe un estándar, pero debe hacerlo de una manera que tenga sentido para usted y contenga toda la información que pueda necesitar para rastrear esa compilación. Trabajé para una compañía que esencialmente lo desglosó así:
[Número de compilación principal]. [Número de compilación menor]. [Revisión]. [Paquete]
es decir, Versión: 1.0.15.2
Número de compilación principal : Esto indica un hito importante en el juego, increméntelo al pasar de la versión beta a la versión, de la versión a las actualizaciones más importantes.
Número de compilación menor : se utiliza para actualizaciones de funciones, correcciones de errores grandes, etc.
Revisión : modificaciones menores en las funciones existentes, pequeñas correcciones de errores, etc.
Paquete : su código permanece igual, cambios de biblioteca externa o actualización de archivos de activos.
Los cambios combinados pasan al cambio más significativo. Por ejemplo, si está incrementando el número de compilación menor, la revisión y el paquete se restablecen a 0.
Aunque las categorías están definidas, todavía hay ambigüedad sobre qué tipo de características se cruzan realmente entre una revisión y un número de compilación menor. Tu decides. Si hace una lista de las características que deberán implementarse antes de cada incremento, también tendrá un plan a seguir, pero al final es su decisión lo que encaja en cada categoría.
Stack Overflow tiene una gran discusión sobre esto llamado Cómo hacer números de versión , que hace referencia a la Guía de estilo de versiones .
Resumen:
Que yo sepa, no hay un estándar para eso. La práctica variará según las empresas, los equipos y los proyectos: no existe una mejor práctica. Lo más importante no es la convención real, sino el hecho de que todos se adhieren a ella.
Dicho esto, el esquema que mencionaste es bastante común para los juegos lanzados. 1.0 normalmente será el maestro de oro, y los parches comenzarán a partir de ahí: 1.1, 1.2 ... También se usa en versiones preliminares para clientes como betas privadas o abiertas.
Para los juegos en desarrollo, rara vez he visto utilizar este sistema. Es mucho más común referirse a una compilación por su ID de cambio atómico (por ejemplo, Perforce número de lista de cambios). Esto es particularmente útil para un proyecto de escala media donde todo (código y activos) se almacena en el mismo repositorio, y la integración continua está en su lugar. En este caso, tener un número de cambio atómico y un número de versión es redundante y propenso a errores. Algunas compilaciones serán promovidas a un hito después del control de calidad: alfa, beta, versión candidata y etiquetadas como tales.
Para grandes proyectos, el concepto simple de una "versión del juego" ya no se aplica. Tendrá varias plataformas, SKU, idiomas, modo para un jugador, modo multijugador, etc. Administrar versiones se convierte en un trabajo de tiempo completo (a veces llamado administrador de datos ; esta es la terminología de Ubisoft, probablemente llamada de manera diferente en otros lugares) , el esquema de etiquetado es mucho más complejo y altamente dependiente del juego real que se está haciendo.