Criterios para poner versión a una aplicación Delphi

[Leviatan]

Hola colegas.

Estuve buscando información en el foro acerca de qué se debe tener en cuenta a fin de poner números de versión a nuestras aplicaciones Delphi, pero no la encontré.

En las opciones de un proyecto Delphi tenemos la opción "Version Info". Luego, en la sección "Module version number" tenemos la versión en sí, compuesta de cuatro partes:


Major version.
Minor version.
Release.
Build.


La primera vez que se crea el proyecto tiene una versión por defecto de 1.0.0.0. La pregunta es: ¿qué se debe tener en cuenta para que la versión, a medida que vayamos sacando nuevas versiones del proyecto, sea por ejemplo una de las siguientes?


1.0.0.1
1.0.2.0
1.1.0.0
2.0.0.0
etc.


También veo que está la casilla "Auto-increment build number" pero seguramente habrá casos en los que no quiero usar esta opción y lo quiera hacer manualmente.

En síntesis, ¿cuáles serían los criterios a tener en cuenta para poner tal o cual número de versión?

Gracias de antemano y saludos.

[roman]

Yo no uso "versionamiento" realmente. Cuando hago algún cambio y lo entrego normalmente rotulo la versión con la fecha de entrega. Supongo además, que es un tema subjetivo y cada cuál establecerá distintos criterios. No obstante, puedes buscar acerca de Versionamiento semántico para darte una idea. Aquí un resumen que he encontrado (https://culturainformatica.co/que-es-versionamiento-semantico-aqui-te-lo-explicamos/):


El número de la versión se identifica con tres dígitos, lo cual es un patrón X.Y.Z y cada posición tiene su significado:


X o major: es cuando se hace un cambio muy grande en el software, se borran o se añaden múltiples funcionalidades. Generalmente la versión anterior a ésta es incompatible con la nueva, por eso; al descargarla para el uso hay que tener consideraciones. Un ejemplo es la reciente versión 3.1.0 de jQuery, a comparación con la 2.2.4 hay muchas cosas que varían, quizá funciones nuevas o algunas removidas que pueden ocasionar incompatibilidad.


Y o minor: Es la manera de agregar una nueva funcionalidad pero esta sigue siendo compatible con la versión anterior. También es considerada cuando se marca algo del software como obsoleto.


Z o patch: Se utiliza cuando se corrigen fallas. No sólo se usa para corrección de funcionalidad, también es posible usar este dígito cuando se cambian aspectos estéticos. La compatibilidad con versiones anteriores se mantiene perfectamente.



LineComment Saludos

[Leviatan]

Muchas gracias roman por tu respuesta.

Yo también me imaginaba que la cuestión de las versiones era algo más subjetivo que otra cosa, pero en el fondo, como en todas las cosas, debe haber algún criterio o al menos recomendaciones acerca de cómo hacerlo, por eso me interesaba hacer esta pregunta para tener un panorama más amplio al respecto.

Voy a buscar el tema que me recomendaste.

Saludos.

[AgustinOrtu]

El sitio oficial es este (http://semver.org/)

Yo recomiendo seguir los lineamientos de ese versionado, en especial para bibliotecas, componentes, frameworks, ya que tus usuarios son desarrolladores, entonces este esquema de versionado nos permite saber si una actualizacion es compatible o no con el codigo que ya tengo funcionando.

Por supuesto que detras de el "numerito" hay un ser humano que puede hacer (como decimos en Argentina) "lo que se le cante", y sacar la actualizacion de 1.2.1 => 1.2.2 que se supone que es compatible con la anterior y en realidad re-implemento el framework entero

Pero todo lo que sea estandares, es preferible seguirlos a ir en contra de ellos. De hecho es asi como cosas grandes (inmensas) como la internet funcionan, sino seria imposible

Saludos

[movorack]

No se si responderá a un estandar pero algunas compañías están optando por versionar con el año, el periodo/trimestre/mes de salida y la versión interna

Algo como:

17.10.1.1

Donde:
17: Año 2017
10: Mes octubre
1: Versión Major
1: Build

[Leviatan]

AgustinOrtu:

Justamente, siguiendo la sugerencia de roman, y leyendo el enlace que me había enviado, me puse a buscar más información y encontré la página en español del sitio que vos mencionás. Se ve muy interesante; nunca antes había prestado mucha atención al tema de las versiones de mis proyectos ya que hasta el momento no tenía necesidad de hacerlo, pero reconozco que es un tema que es importante saber, sobretodo si fuéramos a escribir código que luego será usado por otros desarrolladores.

Gracias también movorack por tu aporte. Ése es un criterio que no lo conocía.

Es realmente enriquecedor tener colaboración de varias personas.

Saludos colegas.

[dec]

Hola a todos,

Desde hace un año o así, personalmente, no me complico demasiado la vida y "versiono" mis programas tal que "2017.1", "2017.2", etc. La primera cifra es el año en curso, y, la segunda es el número de "release" sin más. Sin embargo, también sigo el criterio que apunta Román de añadir la fecha a la "release" en cuestión. Si lo hago de este modo, es, en parte, por un asunto de "marketing", es decir, la versión indica claramente el año de publicación, parece "moderno" (porque lo es), mientras que algo como "10.1.1" no deja clara la fecha de publicación, y, entonces habría que adjuntarla sí o sí, en mi opinión.

P.D. No es un invento mío este "versionado"... yo tomé la idea de LMD (https://lmd.de/), si bien no estoy seguro de que en su caso "complican" más el asunto. En mi caso, ya digo, año de publicación y número de "release". Y de momento no me va mal. :)