[BulmaGés]Consultas a los developers

[Leopold Palomo Avellaneda]

A Divendres 20 Juliol 2007 17:49, Tomeu Borras va escriure:
> > > Hace pocos días hice un cambio para que cada plugin esté en su
> > > directorio. Por ejemplo:
> > >
> > >
> > > trunk/bulmages/bulmafact/src = código básico de bulmafact
> > > trunk/bulmages/bulmafact/plugins = plugins de bulmafact
> > >
> > > Puedes encontrar esta estructura para bulmalib, bulmacont y bulmafact.
> > >
> > > La versión actual (SVN) es 0.9.3 y pico :), porque esa la dejamos ya
> > > atrás y seguimos desarrollando.
> >
> > De acuerdo,
> >
> > entoces la idea es que cada programa tenga su carpeta de plugin, no? me
> > parece perfecto, ya que así, a la hora de empaquetar se tiene más claro
> > que va a cada sitio.
>
> LA versión 0.9.3 es la que está en la rama estable, lo nuevo irá a la
> versión 0.9.5 o 0.9.7 según veamos.

ok perfecto. Pero hay una cosa que no me gusta mucho y que no estoy de 
acuerdo. Yo entiendo que en subversion, al tener:
trunk
branches
releases (tags)

se entiende que: 
trunk es el desarrollo. Ok

releases serian los tags de cvs, y seria como una foto de trunk en un momento, 
con un número, que en nuestro caso seria como decir, ok, trunk está 
suficientemente maduro, hagamos una etiqueta y hacemos una foto en releases.

branches seria como ramas, como pruebas o alternativas. Aquí yo no tengo claro 
que se haya de poner estable. No es una rama. Yo creo que se desarrolla en 
trunk, se etiqueta cuando se diga en tags (releases) y se experimenta o 
hacemos cosas paralelas en branches.

Por tanto yo sacaría la rama estable. Para mi no es una rama. Y mira que yo 
creo que hice el directorio branches/release-0.5.3, pero no va ahí.

> > Viendo los commits que hiciste hace unos días, me recuerdo que hay una
> > cosa que me toca un poco las narices en la estructura del código: la
> > existencia de directorios .moc, .obj, .ui en el repositorio. Además creo
> > que no hay ninguna regla para crearlos, cuando son directorios totalmente
> > temporales de salida de programas. Que os parecería modificar el .pro
> > para que los cree si no existen i sacarlos del svn?
>
> Basta con sacarlos el svn ya que el .pro por defecto los crea si no
> existen. A mi también me disgusta verlos.

pues si os parece bien, hago de mrproper y empiezo a eliminar. Por cierto 
Tomeu, tu que conoces bien los .pro, que tal añadir un rm -rf o delete de 
los .obj, .ui y .moc? se puede hacer?
>
> > También, hay otra cosa que no encuentro muy oportuna. Las traducciones
> > van a un directorio /traducciones que os parecería cambiar el nombre por
> > i18n?
>
> Ese no es el peor de los problemas, el problema real es que cada plugin va
> acompañado se sus respectivas traducciones y el control de todos estos
> archivos va a ser duro.

por qué? es parte del código fuente. No entiendo el problema, por favor puedes 
explicarte?

> Estoy planteando si no será mejor que los .pro generen los ts directamente
> dentro del installbulmages (mala idea) o en un directorio específico para
> traducciones para luego tener las traducciones agrupadas y controladas.

si los plugins siempre van ligados al programa, quiero decir que no es posible 
plantear un paquete aparte, ponlos donde quieras, ya que luego el 
empaquetador los instala donde crea oportuno.

> > Otra cosa, que pasos se han de seguir cuando se instalar bulmages sobre
> > una instalación ya hecha? Qué se hace con las bases de datos?
>
> El script installbulmages-server se repasa las bases de datos creadas y les
> aplica los oportunos parches que hacen falta para esa base de datos
> (También hace backups por si las moscas, etc). Asi que por esta parte esta
> solventado. Sólo requiere que los desarrolladores sean concienzudos con los
> archivos sql de actualización.

Ya, pero como? quiero decir, se ha de hacer un proceso manual en el que el 
instalador llame a ese script? o lo ha de hacer el usuario cuando actualiza?
Por cierto, el lanzador lo he puesto en el 0.9.3.


Leo
-- 
--
Linux User 152692
PGP: 0xF944807E
Catalonia
------------ próxima parte ------------
Se ha borrado un mensaje que no está en formato texto plano...
Nombre     : no disponible
Tipo       : application/pgp-signature
Tamaño     : 189 bytes
Descripción: no disponible
Url        : http://llistes.bulma.net/pipermail/bulmages/attachments/20070720/0aef3907/attachment.pgp