De versiones estables, betas y demás

[dec]

Hola,

Tengo una pregunta que haceros, a ver si podéis sacarme de dudas. Supongamos que acabas de publicar una versión "estable" de cierto programa, pero, no por eso vas a dejar de seguir trabajando en el mismo, de modo que también dispones de una versión "beta", para quien quiera contar o probar "los últimos cambios llevados a cabo".

Ahora bien, dos días después de publicar dicha versión "estable" llevas a cabo alguna mejora, digamos en el sistema de "plugins" conque cuenta tu aplicación, y claro, cualquier plugin creado a partir de ahí, no podrá ser usado en la versión "estable", pues esta no ha sufrido los cambios que decimos. De modo que los usuarios de esa versión "estable" no podrán usar el plugin en cuestión.

Ahora bien, ¿qué hacer? Propondré un par de alternativas que me rondan por la cabeza, pero, agradecería vuestras respuestas y comentarios, puesto que, sinceramente, no soy capaz de salir de dudas, y eso que podría "fijarme" en otros programas, pero, no me queda claro aún así. Además, puede que resulte un tema interesante de tratar, que tal vez fuera útil para alquien más, quiero decir.

Las alternativas que se me ocurren son:

1º No actualizar la versión estable, porque, ¿entonces cómo la consideraríamos estable, precisamente?

2º Actualizar la versión estable, puesto que, los cambios introducidos no la hacen "inestable".

Como veréis, no me queda nada claro cómo tiene que ser exactamente la versión estable de un programa. Así pues, ¿qué entendéis vosotros por versión estable? ¿Y qué opiniáis de la situación en que me encuentro? ¿Qué debería hacer? Gracias de antemano por vuestra ayuda. :)

[mightydragonlor]

ps yo creo de manera muy personal, que no debes de incluirla aún, ya que poco a poco resultan mas inclusiones en el aplicativo, esto es perfectamente normal, además de eso se tratan las versiones estables, contienen todas la mejoras realizadas cada cierto tiempo.

[Delphius]

Hola David,
En lo personal considero a la palabra estable como "lo suficienemente probado o testeado como para haber pasado y superado los requisitos planteados".
Por ello, si el sistema sigue evolucionando, y mientras no se cumplan todas las pruebas pactadas, seguirá habiendo una versión inestable, o beta, si desen llamarla.

La cuestión es que para mi, debe existir paralelamente dos versiones: las estables y las betas. Se va actualizando la versión beta a medida que se avanzan las pruebas. Cuando las pruebas finalizen se podrá aceptar a dicha versión como estable. Esta versión se añade al repertorio.

Se continúa el proceso mientras sea viable el proyecto.

Ya queda a gusto de uno como lleva a cabo el control de versiones, lo importante es que no se deseche, y nunca "pisar" las versiones estables. Puesto que en caso de bugs, se puede volver atrás.

No se si se me entiende la idea.
Por tanto amigo, yo añadiria una tercer opción:
Actualizar la versión inestable y dejar la estable tal como está.

Saludos,

[Casimiro Notevi]

1º No actualizar la versión estable, porque, ¿entonces cómo la consideraríamos estable, precisamente?


Las nuevas funcionalidades, mejoras, etc irán en la siguiente versión, incluso aunque estas cosas nuevas funcionen perfectamente. Una versión "estable" es una versión "final", ya no se toca hasta la siguiente versión, salvo que sea un arreglo crítico o algo así, que en todo caso sería la versión 1.0.1

Es mi opinión. :)

Además que si es algo nuevo interesante, la gente estará más ansiosa de que salga la versión siguiente para tenerlo :)

[dec]

Hola,

Gracias por vuestras sugerencias: me va quedando el asunto más claro. ;)

[AntonioTB]

Hola.
El tema es realmente interesante, la solución es sencilla en su concepción, pero tiene trabajo en la intrumentación. Me explico.

Primero hemos de usar un software que nos permita el control de versiones, si no nos podemos volver locos con los cambios, adiciones y similares.
A partir de esto, cuando terminamos la versión y la consideramos estable, la marcamos y generamos una nueva versión, la beta.
A mí personalmente me gusta el sistema de linux de numeración. Primer dígito para la versión. Segundo dígito para la revisión y tercero para pequeños cambios o actualizaciones. En el segundo dígito suelo usar un número para para versiones estables, y uno impar para versiones de prueba.
Cuando empiezas una versión, lo lógico es tenerla en una carpeta nueva, que incluya normalmente el número de versión principal y el de revisión.
A partir de aquí desarrollas normalmente.

El problema suele venir con los 'apaños' que debemos intentar que no modifiquen la funcionalidad, sino que sólamente corrijan fallos. La forma de que al arreglar los errores en una versión se modifique el código en las otras, el mejor modo es usar las herramientas que vienen con el control de versiones y que nos permiten hacer un 'diff' del fichero de código y trasladar las modificaciones fácilmente. (Depende de la herramienta de control de versiones el que sea sencillo o complicado.
Si activamos la casilla de guardar los formularios de delphi como texto esto nos permite hasta el trasladar los cambios hechos en la apariencia del formulario de un proyecto a otro sin apenas trabajo. y almacenar los cambios realizados a los formularios con gran detalle.

Espero que esto te haya aclarado algo.
Aparte este método tiene la ventaja de que varias personas pueden trabajar en el proyecto, desde distintos equipos siempre que se siga un criterio ordenado para aplicar los cambios en el control de versiones.

Un saludo, Antonio.

[Delphius]

Hola.
El tema es realmente interesante, la solución es sencilla en su concepción, pero tiene trabajo en la intrumentación. Me explico.

Primero hemos de usar un software que nos permita el control de versiones, si no nos podemos volver locos con los cambios, adiciones y similares.
A partir de esto, cuando terminamos la versión y la consideramos estable, la marcamos y generamos una nueva versión, la beta.
A mí personalmente me gusta el sistema de linux de numeración. Primer dígito para la versión. Segundo dígito para la revisión y tercero para pequeños cambios o actualizaciones. En el segundo dígito suelo usar un número para para versiones estables, y uno impar para versiones de prueba.
Cuando empiezas una versión, lo lógico es tenerla en una carpeta nueva, que incluya normalmente el número de versión principal y el de revisión.
A partir de aquí desarrollas normalmente.

El problema suele venir con los 'apaños' que debemos intentar que no modifiquen la funcionalidad, sino que sólamente corrijan fallos. La forma de que al arreglar los errores en una versión se modifique el código en las otras, el mejor modo es usar las herramientas que vienen con el control de versiones y que nos permiten hacer un 'diff' del fichero de código y trasladar las modificaciones fácilmente. (Depende de la herramienta de control de versiones el que sea sencillo o complicado.
Si activamos la casilla de guardar los formularios de delphi como texto esto nos permite hasta el trasladar los cambios hechos en la apariencia del formulario de un proyecto a otro sin apenas trabajo. y almacenar los cambios realizados a los formularios con gran detalle.

Espero que esto te haya aclarado algo.
Aparte este método tiene la ventaja de que varias personas pueden trabajar en el proyecto, desde distintos equipos siempre que se siga un criterio ordenado para aplicar los cambios en el control de versiones.

Un saludo, Antonio.

Tener una buena herramienta de control de versiones es una buena opción. Pero más que herramienta es necesario ser ordenado. Si uno no es "prolijo" en sus proyectos de desarrollo, difícilmente que por más herramientas que tenga vaya a conseguir algo bien bonito.

No es por contradecirte, es tan sólo mi opinión.

Tengo una duda por lo que comentas sobre el uso de la versiones en Linux para designar cuando es estable y cuando no. Según lo que leo aquí (http://es.wikipedia.org/wiki/Fases_del_desarrollo_de_software#Estable.2Finestable) ese sistema ya no se sigue usando. ¿Podrías aclararme el panorama por favor? No uso Linux, pero me llamó la atención esta discrepancia.

Saludos,

[AntonioTB]

Hola Delphius.

No te preocupes, no me llevas la contraria, sino que me das la razón.
Obviamente hay que ser muy ordenado en los métodos para llevar un control correcto de las versiones de los programas que desarrollas.
El motivo de indicar la necesidad/idoneidad de un software de control de versiones es por la mejora del trabajo cotidiano que hay que hacer para mantener las diferentes versiones, y simplificarlo en la medida de lo posible.
Una ventaja adicional de este tipo de software es la realización de copias de seguridad, puesto que siempre disponemos de al menos dos versiones de todo, la que hay en el equipo y la que está almacenada en dicho software.
Si a todo esto añadimos que se nos permite una sincronización del trabajo más o menos restrictiva entre varios miembros de un equipo, cuando atacamos problemas con una cierta entidad, dos o más personas pueden estar simultáneamente trabajando sobre el mismo proyecto.

Con respecto a lo de Linux, ha sido una sorpresa el ver que ya no siguen con el sistema de numeración. Yo lo recordaba de cuando el kernel 2.1 y 2.0, de esto hace ya casi diez años, (al menos).
Me pareció una buena idea y por eso lo adopté y lo he usado en varios proyectos.

[MAXIUM]

Pués muy simple, nunca publiques versiones estables, es decir con la palabra "estable o final" a menos que ya no quieras seguir desarrollandola.

[dec]

Hola,

Gracias por vuestros comentarios. Parece quedar claro que la versión estable no debe cambiarse ni actualizarse,... hasta la siguiente versión estable. A no ser que igual hubiera algún problema, en cuyo caso sacaría una nueva versión (menor) estable con los problemas corregidos.


Pués muy simple, nunca publiques versiones estables, es decir con la palabra "estable o final" a menos que ya no quieras seguir desarrollandola.


Hombre, con lo de la versión final estoy de acuerdo, pero, con lo de la versión estable no. Llevo con el proyecto varios meses, y la cantidad de cambios que se han hecho, a veces cada hora, no creo que animase a nadie a instalar el programa. Ahora puedo seguir haciendo tantos cambios como necesite, pero, sobre una versión que no es la estable, que no es la que se ha decidido que puedes instalar y trabajar con ella, porque se ha probado lo suficiente para que sea así.

Evidentemente, dentro de X meses, aparecerá una nueva versión estable, y tú verás si actualizas o no, pero, no es lo mismo plantearte esa situación cada X meses que hacerlo cada día...