[BulmaGés]Revisiones y versiones

[Leopold Palomo Avellaneda]

A Dilluns 23 Juliol 2007 12:21, Tomeu Borras va escriure:
> Porfin !!! Ahora ya si puedo contestar al mail directamente. El kmail me la
> ha jugado con este correo.
>
> > Bones,
> >
> > hay un punto que no veo muy claro y ayer tarde lo hablé con Tomeu: es el
> > tema de como numerar y donde ubicar las versiones. No creo que exista el
> > concepto de versión estable y en esto difiero de Tomeu. No me lo creo. Lo
> > que si veo es que se podría tener series, por ejemplo la 0.9.X que en una
> > época determinada fuera la serie estable.
> >
> > La estructura habitual en SVN es trabajar en 'trunk', hacer pruebas
> > en 'branches' y liberar versiones estables en 'release'.
>
> Cierto, yo creo que el fallo estaba en que el directorio estable debería
> llamarse released. Y así no se presta a confusión.

Ok, estamos de acuerdo. 

> > Tomeu comentaba que el desarrollo principal y los experimentos se hacen
> > en 'trunk', sin tener en cuenta el directorio branches. No estoy muy de
> > acuerdo, pero lo acepto.
> >
> > En el tema de la liberación de versiones es donde yo estoy en desacuerdo
> > con Tomeu y aunque al final de la conversación habíamos llegado a
> > un entendimiento, creo que seria bueno tener más opiniones.
> >
> > Creo que el planteamiento de Tomeu es parecido al de debian: con una rama
> > estable, una inestable y una testing. Mi planteamiento es más parecido al
> > de una aplicación estandard.
>
> No como debian. En realidad se trata de tener un sitio donde programar y un
> sitio a partir del cual los usuarios tengan sus instalaciones. Para poder
> arreglar los problemas de los usuarios y poder seguir desarrollando. Y todo
> ello con el menor esfuerzo posible en inversión de recursos.

Ok.

> > Yo creo, y en eso Tomeu y yo estamos de acuerdo, que la numeración
> > principal de las versiones se tendría que fundamentar en la versión de la
> > base de datos y quizás también en la versión (ABI) de las librerías. Así,
> > la versión 0.9 se basa en una estructura determinada de la base de datos
> > y en una versión fija de las bulmalib.
> >
> > Mi propuesta es que cuando se tenga en el trunk una versión que se
> > considera que puede ser estable, se haga una copia en el directorio
> > 'release' o 'tags' o llame se como se quiera. El nombre debería ser en
> > nuestro caso actual 0.9 (es decir el número de la versión en al que se
> > basa).
> >
> > Al mismo tiempo se está trabajando en trunk en la serie, por ejemplo,
> > 0.10.x que necesita las qt 4.3, etc.
> >
> > Actualmente tenemos una versión estable, que yo lo llamaría la serie 0.9.
> > El siguiente número de la versión, muestra el nivel de parcheo. Ahora
> > estamos el la versión de parcheo de bugs, etc 0.9.3. Quiero decir que si
> > la estable es ésta, no implica que no salgan cosas o arreglos. Todo lo
> > contrario, el último número muestra el nivel de parcheo.
> >
> > Si tenemos una rama que sea la 0.9, en esta se arreglan las cosas, o se
> > añada documentación, etc. pero lo importante es que no se cambie la base
> > de datos de forma que si se tiene instalado la 0.9.x se pueda instalar
> > encima una 0.9.y (x < y) de forma muy segura, porque la base de datos es
> > la misma y solamente se cambian o arreglan cosas mínimas. Los arreglos
> > que se hagan a la 0.9.3 darán lugar a la 0.9.4 que también será estable y
> > mejorada.
> >
> > Los splash los dejaría etiquetados por series, o sea que no aparezca el
> > patch level .x último, de forma que esa parte no se tuviera que cambiar y
> > únicamente en el arranque de la aplicación apareciera en texto, el nivel
> > de arreglo 0.9.X (aparte del botón Acerca de). Los scripts de
> > actualización de base de datos serian por series.
>
> Hay que decir que los problemas son muchos. Estamos tocando bulmalib cada
> dia. La base de datos también esta modificandose muy a menudo. No se puede
> utilizar esa notación hasta que se pueda hacer un trabajo sin tener que
> andar tocando bulmalib muy a menudo. Pero hoy por hoy eso no es posible.

Y no es posible plantear en trunk todos los cambios posibles y una vez visto 
que es suficientemente estable, lanzarlo como nueva versión?

> > Respecto al tener un directorio etiquetado como estable, etc. Ayer
> > descubrí una cosa que tiene subversión que no sabia: las propiedades
> > externas. Así como los enlaces simbólicos funcionan, pero no en la forma
> > que pueda hacer un checkout de un enlace. Pero se puede poner un
> > directorio vacío, y cambiar sus propiedades, de forma que se podría hacer
> > un directorio donde las propiedades sean hacer chekout de otros sitios:
> >
> > svn propset svn:externals --file props release-stable
> >
> > donde el fichero props contiene:
> > stable-tomeu
> > http://svn.berlios.de/svnroot/repos/bulmages/branches/estable
> >
> >
> > Es un correo un poco largo y complejo. Me lo ha revisado la Laida (y
> > parcheado ;-) así que por favor os pido que os lo leáis con calma y que
> > comentemos las cosas que no hayan quedado claras o no estéis de acuerdo.
>
> El problema es que lo planteado es muy teórico y en la práctica acabarás
> teniendo algo del estilo.
>
> 0.9.0
> 0.10.0
> 0.11.0
> 0.12.0
> ...
> ...
> ...
>
>
>
> A pesar de que mi opinión sea pesimista hagamos lo lógico. Probemoslo, y
> siempre podemos volver a cambiar si no funciona.
>
Por mi vale, y yo me encargo pero con dos condiciones:

- cuando los principales desarrolladores veáis que tiene opciones de ser una 
estable nueva (o versión nueva) yo hago el movimiento, marcamos número nuevo 
y trunk se aparca unos días hasta tener aquello ok. 

- cada versión de esta, en su serie la estructura de la base de datos no se 
toca!!! sólo se arreglan bugs, pequeñas cosas y documentación. Pero se ha de 
poner instalar sobre otra de la serie sin ningún tipo de problema de la base 
de datos. Solo a nivel de código.

Leo
-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia