Preparación:

Copiar a algún directorio, y meterlo en path, los scripts de python que se han dejado en el proyecto install del workspace (concretamente install/scripts/svnScripts). Estos scripts realizan en batch algunas tareas con el svn y nuestro workspace que veremos a continuación.

En el archivo svn-utils.py debemos sustituir en la linea 32 las cadenas "USUARIO" y "PASSWORD" por los valores correspondientes a nuestro usuario en el repositorio.

Pasos a seguir:

Nota: Los ejemplos se han puesto considerando que la versión de gvSIG cuyo instalador se va a generar es la 1.11.0. Si se va a generar un instalador de una versión posterior, sustitúyase donde aparezca 1.11.0 o 1_11_0 por la versión correspondiente. Si ha cambiado la versión de gvSIG, ahora solamente hay que cambiarla en el archivo package.info del proyecto appgvSIG en las propiedades version y gvSIG-version.

1.- Comunicar a la lista de desarrollo el número de versión y esperar un poco para que suban sus cambios (mirar en el archivo build.number de la extensión actual e incrementarlo en uno )

ejemplo:

Hola,

Se va a generar inmediatamente un nuevo build de gvSIG 1.11 para testing.
Este build se extraerá del Trunk.

Si tenéis algo pendiente, subidlo ya.

Saludos.

2.- Quitar el build automatically.

3.- Sincronización con el svn:

svn update *

4.- Hacer clean-all y build all del build.xml de appgvSIG para el workspace (a través de external tools).

5.- Refresh para todo el workspace.

6.- Comprobar que gvSIG arranca y carga lo que esperamos

7.- Ejecutar en consola de shell en el directorio del workspace:

svn update *

para descargar los cambios.

7.1.- Si no hay cambios (esto se mira en la ventana del shell), se pasa al siguiente punto.

7.2.- Si sí los hay, se hace sincronize y se bajan los cambios, y se repite todo desde el punto 4 (clean all y build all) hasta que en este punto no haya cambios.

8.- Ejecutar en consola de shell en el directorio del workspace:

svn-preparar_tag trunk pre_v1_11_0_Build_xxxx

donde xxxx es el el nuevo build number (indicado en el punto 1). Esto hace que se copien los proyectos desde el trunk al tag/tmp_build/ (se realiza remotamente en el servidor sin hacer una copia en local).

9.- Cerrar eclipse

10.- Ejecutar en consola de shell en el directorio del workspace:

svn-sw_ToTmp_workspace

Esto hace un switch para cada uno de los proyectos a la nueva ubicación (tag/tmp_build).

11.- Hacer clean-all y build all del build.xml de appgvSIG para el workspace (a través de external tools). Comprobar que gvSIG arranca y carga lo que esperamos.

12.- Si hay que cambiar etiquetas de distribución (alpha, beta, RC1, ...) o número de versión cambiarlas en el:

install/instalador-gvSIG-lin/installer_files/LEEME (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-lin/installer_files/README (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-win/installer_files/LEEME.txt (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-win/installer_files/README.txt (Aquí solo en caso de cambio de número de versión)
install/build.properties (Aquí solo en caso de cambio de número de versión)
install/instalador-gvSIG-lin/install_template.xml (appname y appversion.
        Hay que asegurarse de no dejar espacios y sustituirlos por guiones bajos)
install/instalador-gvSIG-win/install_15_template.xml (appname y appversion.
        Hay que asegurarse de no dejar espacios y sustituirlos por guiones bajos)
_fwAndami/theme/andami-theme.xml (en dos sitios)
appgvSIG/package.info.

13.- Ahora desde external tools configurations ejecutamos el target make-binary-distribution del build.xml del proyecto appgvSIG . Esto hace que se incremente el build number de gvSIG.

14.- Comprobar que gvSIG arranca y carga lo que esperamos. Comprobar en el about de la aplicación que el build number es el que toca.

15.- Finalmente ejecutamos los siguientes targets del build.xml del proyecto install:

• check,
• linux* y
• windows*

NOTA:

Durante la ejecución de estos dos targets, el proceso se parará y mostrará un cuadro de dialogo con el texto "Instale en este momento las contribuciones externas y después continúe con este proceso. Cuando el instalador pregunte el lugar donde está instalado gvSIG, proporciónele la ruta al directorio prev_install que se ha creado nuevo en el directorio INSTALL de su workspace. ¿Desea continuar ahora?". Si queremos incoporar dichas contribuciones debemos hacerlo ahora:

• Si tenemos paquetes de instalación para Linux los ejecutamos (tanto si estamos ejecutando el target "linux" como el "windows") y le suministramos (como dice el texto) la ruta al directorio prev_install del proyecto install del workspace.
• Si no, copiamos la extensión correspondiente al directorio prev_install/bin/gvSIG/extensiones que se ha creado nuevo en el directorio install de su workspace

Debemos asegurarnos de que se han copiado correctamente los ficheros "package.info" dentro de cada una de las extensiones incorporadas, y que el contenido de ellos es el que corresponde.

Para continuar con el proceso, seleccionamos "Sí" en el desplegable y pulsamos "OK".

Puede ser recomendable la ejecución de estos targets desde línea de comandos:

- ant -f build.xml check Linux
- ant -f build.xml check Windows

porque con las modificaciones que se han incorporado para la inclusión de las contribuciones externas, al ejecutarlos desde eclipse, se pierde la salida de la consola y no podremos ver si ha ocurrido algún error posterior a este punto.

16.- Se generan cuatro archivos, dos para windows y dos para linux (con y sin jre).

17.- Instalamos la aplicación para probarla y verificamos que la versión es la correcta (en el menú help/about tiene que figurar el nuevo build number).

18.- Si todo va bien subimos los archivos al servidor ftp de osor dentro de la carperta:

/home/groups/gvsig-desktop/www/downloads/pub/projects/gvSIG-desktop/devel/gvSIG-1_11/gvSIG-1_11_0/XXXX

donde XXXX es el nuevo build number (indicado en el punto 1)

19.- Si hemos cambiado etiquetas de distribución (alpha, beta, etc.) (pto. 12) habrá que subir estos cambios al tag en un solo commit.

20.- Cerrar eclipse.

21.- Ejecutar en consola de shell en el directorio del workspace:

svn-sw_workspace trunk 

Esto hace un switch para cada uno de los proyectos a la ubicación original (trunk).

22.- Ejecutar en consola de shell en el directorio del workspace:

svn-merge_workspace_with_tmp_build

Esto hace un merge para cada uno de los proyectos a la ubicación original (trunk).

23.- Hacer commit en el trunk con los cambios que hemos hecho en el tag. El mensaje del commit será v1_11_0_Build_xxxx donde xxxx será el número de build

24.- Desde el svn explorer de eclipse u otra utilidad renombrar el tag tmp_build a v1_11_0_Build_xxxx. El mensaje del commit será v1_11_0_Build_xxxx donde xxxx será el número de build

25.- Crear un ticket de tipo nota en el bugtracking (tomar como plantilla anteriores tickets de este tipo, por ejemplo del build 1305 https://forge.osor.eu/tracker/index.php?func=detail&aid=15259&group_id=89&atid=804). No olvidar en el mismo comentario poner el enlace a las descargas de los binarios.