Versionando aplicaciones Android

Por Armando Picón - hace 2 años

Sección: Tech


Si necesitas mejorar el esquema de versionamiento de tu aplicación Android, entonces estás leyendo la publicación correcta. Descubramos juntos algunas buenas prácticas y sus ventajas.

Versionamiento Semántico

Existe algo en el mundo del software llamado Versionamiento Semántico. Esto consiste en un par de convenciones para asignar números de versión para tu software. Puedes (o tal vez debas) leer todos los detalles aquí.

Básicamente, la idea es la siguiente:

Dado un número de versión PRINCIPAL.MENOR.PARCHE (MAJOR.MINOR.PATCH), incrementa la:
Versión PRINCIPAL (MAJOR version) cuando realizas cambios no compatibles en la API.
Versión MENOR (MINOR version) cuando agregas una funcionalidad en una manera compatible al API ya existente, y
Versión del PARCHE (PATCH version) cuando realizas correcciones de ‘bugs’ compatibles con el API ya existente.

Como podrás ver, de acuerdo a la definición anterior, la versión PRINCIPAL en una aplicación android no tiene mucho sentido a menos que tengas algún tipo de API para ser consumido por otro cliente. Si ese es el caso, entonces puedes emplear la definición pura de Versionamiento Semántico. Si no, necesitas definir cuándo deberías incrementar la versión PRINCIPAL.

Una opción podría ser, incrementar la PRINCIPAL cuando tu aplicación tenga una nueva funcionalidad, resideño o meta grande completada. Otro enfoque es incrementar la PRINCIPAL después que la versión MENOR alcance el número 9. Por ejemplo, podrías tener las versiones 1.0.0, 1.1.0, … 1.9.0 y luego 2.0.0. Es solo una convención para decidir cuándo incrementar la PRINCIPAL.

En mi caso, empleo el segundo enfoque, pero tu puedes emplear cualquiera, con tal que esté bien definido y sea entendible por los interesados de tu aplicación.

Pre-lanzamientos

Otro concepto definido por el Versionamiento Semántico es la versión de pre-lanzamiento (pre-release version). Una versión de pre-lanzamiento puede ser denotada por medio de la adición de clasificador de versión que empieza con un “-”. Por ejemplo “3.1.0-beta”, “1.2.0-rc”, “4.1.3-preview”, “2.3.0-alpha”, “1.3.2-SNAPSHOT”.

Puedes emplear estos clasificadores de versiones para identificar rápidamente el tipo de versión de tu aplicación y evitar confusiones entre una versión pre-lanzamiento y una versión lanzamiento. Por ejemplo, en mi caso empleo “-SNAPSHOT” durante la fase de desarrollo y remuevo ese clasificador antes del despliegue del APK.

Si empleas el programa Google Play Alpha/Beta Testing toma en cuenta no es una buena idea subir un APK con un nombre de versión que termine en “alpha” o “beta”. La razón es que cuando promocionas un APK a producción, no podrás cambiar el nombres de la versión, entonces los usuarios van a creer que ellos han instalado una versión inestable.

Código de versión y nombre de versión

Como sabrás, en android debes definir dos campos de versión para una aplicación: el código de versión (android:versionCode) y el nombre de versión (android:versionName). El código de versión es un entero incremental que representa la versión del código de la aplicación. El nombre de versión es un texto que representa el nombre de versión “amigable” para los usuarios. Puedes obtener más detalles aquí.

Es una buena práctica contar con una relación directa entre ambos valores para evitar confusiones durante el proceso de desarrollo y despliegue. Al menos, deberías poder inferir el nombre de la versión según el código de versión.

Como está descrito aquí, la documentación oficial propone el uso de unesquema de código de versión que asocie tanto el código como el nombre de versión, y también soporta la carga de múltiples APK al Google Play.

Yo sugiero emplear una adaptación de ese esquema para darle soporte también al Versionamiento Semántico (asumiendo que necesites dos dígitos para la versión PRINCIPAL, dos para la versión MENOR y dos más para la versión de PARCHE).

Mi sugerencia es emplear un código de versión de 9 dígitos: enteros que representan las configuraciones que son soportadas en los bits de orden mayor (higher order bits), y el nombre de versión en los bits de orden menor (lower order bits). Los primeros dos dígitos representan el mínimo nivel de API que soporta tu APK. El siguiente dígito es tanto para los tamaños de pantalla como para los formatos de texturas GL (se asigna cero si no se necesita emplear esto). Luego se toman dos dígitos para la versión principal, dos para la versión menor y los últimos dos para la versión del parche.

Por ejemplo, cuando el nombre de versión de la aplicación es 3.1.0, el código de versión para un nivel 4 de API podría ser algo como 040030100. Los primeros dos dígitos están reservados para el nivel mínimo de API (4 en este caso), el tercer dígito es tanto para los tamaños de pantalla o los formatos de textura GL (al no emplearse en este ejemplo, se asigna el valor 0), y los últimos seis dígitos son para el nombre de la versión de la aplicación.

 

Como puedes ver, puedes ir desde la versión 0.0.1 hasta 99.99.99. Entonces, tienes espacio para más de 40 años de versiones, desplegando cada dos semanas y sin tomar en cuenta los ‘hot fixes’.

Automatizar el esquema de versionamiento con Gradle

Si empleas Gradle para armar tu aplicación (y espero que sea así) puedes automatizar el esquema de versionamiento incluyendo el siguiente código en tu build.gradle.

https://gist.github.com/maxirosson/48c0d8160c758a9145e6

Solo debes configurar el versionMajorversionMinorversionPatch,versionClassifier y el minimumSdkVersion para generar automáticamente los valores del versionCode y el versionName.

Conclusion

Para resumir, aquí están mis cuatro principales sugerencias:

  • Emplea versionamiento semántico, o una adaptación de él, de acuerdo a tus necesidades.
  • Emplea un esquema de versionamiento que relacione el código de versión con el nombre de versión. Debería permitirte inferir el nombre de versión según el código de versión.
  • Emplea un esquema de versionamiento que soporte multiples cargas de APK a Google Play. Tal vez no necesites múltiples APKs ahora, pero podrías necesitarlos en el futuro.
  • Emplea Gradle para generar automáticamente el código de versión y el nombre de versión de tu aplicación.

Trata de seguir estas sugerencias desde el día cero de tu aplicación para evitar posibles dolores de cabeza en el futuro.

Español: El artículo original se encuentra aquí. Esta es una traducción del artículo Versioning Android Apps de Maxi Rosson.

Autor del artículo

Armando Picón

Soy desarrollador de software, certified scrum developer y organizador del GDG Open Lima.
Software Developer & #GDGOpen organizer

Comentarios