Nombrado de binarios para un plugin de gvSIG
:Version: 1.5
Antes de plantearnos hablar sobre el nombre de fichero que va a llevar
el fichero con nuestra distribución deberemos tener claro al menos:
- El nombre corto o código de nuestro plugin.
- El número de versión de nuestra distribución. Es aconsejable que lea
el documento `Interpretación del número de versión en gvSIG`_ para
familiarizarse con los números de versión en gvSIG.
- Para qué plataformas vamos a generar la distribución.
- El estado del desarrollo, alpha, beta, RC, final,...
- Y la versión de gvSIG para la que se ha de realizar el empaquetado.
Una vez dispongamos de esta información podemos pasar a ver que
criterio seguimos para dar nombre al fichero de nuestra distribución.
La primera consideración sería que el nombre de los ficheros debe ir todo
en *minúsculas*.
El formato a usar para el nombre sería::
gvSIG-desktop---__---.
Donde:
- *gvsig-versión* es el número de versión de gvSIG, en el formato de::
_
No se especifica ni el número de revisión ni el de build ya que entre estas
versiones se espera no haya cambios en el API.
- *name*, será el nombre corto o código del proyecto.
- *major number*, *minor-number*, *revision-number*, y *build-number*, identificarán la versión del proyecto. Dependiendo de la versión de gvSIG para la que se publique la extensión, se recomienda usar un *major-number* distinto si la extensión está disponible para distintas versiones de gvSIG con *major-number* distinto, a su vez. Por ejemplo, si la extensión está disponible para gvSIG 1.x y para gvSIG 2.x, podríamos tener como *major-number* de la extensión *1* y *2* respectivamente. Lo importante es que sean distintos para evitar confusiones, no que coincidan con los de gvSIG.
- *state* será:
- *devel*, para versiones en desarrollo.
- *pilot*, para pilotos de plugins. Los pilotos normalmente son usados
en concursos para afianzar una oferta y no suelen tener una funcionalidad
completa ni libre de errores.
- *prototype*, se trataría de una *prueba de concepto* que sirve a los
desarrolladores para verificar una idea de cómo abordar un desarrollo,
pero que en versiones futuras no tiene por que seguirse esa línea.
- *testing*, para versiones sobre los que se va a realizar un proceso de testing,
previo a ser cambiado a los estados de *alpha*, *beta*, etc.
- *alpha*
- *beta*
- *RC*, seguido de un número (*RC1*, *RC2*, ...) identificaria a las
*release candidates* previas a la versión *final* del producto.
- *final*, que identificaría a una versión final del plugin.
Un desarrollo no tiene por que tener todos estos estado, pero sí que
el estado de una distribución deberá estar entre ellos.
- *platform* nos da informacion sobre:
- El sistema sobre el que se ejecuta, *windows*, *linux*, *mac*
o *all* cuando es independiente del sistema.
- La arquitectuta de hardware
- La minima version de la maquina virtual de java requerida.
Segun esto tendremos:
- *all-all-j1_5*, para binarios compilados
para la máquina virtual de java versión 1.5.X que
sean independientes del sistema y la arquitectura hardware.
- *all-all-j1_6*, para binarios compilados
para la máquina virtual de java versión 1.6.X que
sean independientes del sistema y la arquitectura hardware.
- *win-i586-j1_5*, para los binarios para *MS Windows* compilados
para la máquina virtual de java versión 1.5.X.
- *win-i586-j1_6*, para los binarios para *MS Windows* compilados
para la máquina virtual de java versión 1.6.X.
- *lin-i586-j1_5*, para los binarios para *linux* compilados
para la máquina virtual de java versión 1.5.X.
- *lin-i586-j1_6*, para los binarios para *linux* compilados
para la máquina virtual de java versión 1.6.X .
- *mac_10_4-i586-j1_5*, para los binarios para *Mac OS* versión 10.4 compilados
para la máquina virtual de java que incluye de base esa versión
de Mac (java 1.5).
.. warning::
Se está evaluando sustituir el modificador de plataforma *"i586"* por
otro que identifique mejor la plataforma. Estando actualmente más
vigente la identificación de la arquitectura 32bits frente a 64bits
y no pareciendo tan importante la distinción entre un i586_ o un i686,
estamos planteandonos el uso de x86_ y x86_64_.
.. _x86 : http://en.wikipedia.org/wiki/X86
.. _x86_64 : http://en.wikipedia.org/wiki/X86-64
.. _i586 : http://en.wikipedia.org/wiki/i586
- En lo que respecta a las extensiones, estas serán:
- *exe* para los instalables de *MS Windows*.
- *bin* para los instalables de Linux.
- *zip* para los instalables de Mac y las versiones multiplataforma.
Para las distribuciónes de fuentes el formato será::
gvSIG-desktop---__---src.zip
Por último también hay que tener en cuenta que cuando se distribuyen versiones de documentación maquetada, el formato
de esta deberá ser PDF y el formato para nombrarlo será::
gvSIG-desktop---_-man-v-.pdf
Donde:
- *man-versión*, será el número de versión del manual. Para una versión de un producto se pueden
generar varias versiones del manual. Normalmente la versión del manual que se dispone a la salida
de la distribución es mejorada en las siguientes semanas o meses, y se publica una versión
actualizada del manual sin que se vuelva a crear una nueva distribución de la aplicación.
- *lang-code*, identifica al idioma en el que se encuentra el manual. Se usarán los códigos ISO639_
*Alpha-2 code space* siempre que sea posible para ello.
Para las distribuciónes de fuentes y documentación no se hace distinción
entre plataformas.
.. _ISO639 :
.. _`Interpretación del número de versión en gvSIG` : /web/reference_catalog/lookupObject?uuid=99467e3828f3fe1a25ef5b6c96d17a13
.. list-table:: Registro de cambios
:header-rows: 1
* - versión
- Descripcion
* - 1.1
- Añadido *gvsig-versión*.
* - 1.1
- Añadido el *status*
* - 1.2
- Corregido error en el formato. La colocacion del *state* era incorrecta.
* - 1.3
- Añadido *devel* como un valor mas de state.
* - 1.4
- Modificado el literal *gvSIG* del inicio del nombre del fichero por *gvSIG-desktop* y
modificada la plataforma para dar soporte a *all*.
* - 1.5
- Sustituir *status* por *state* y añadir nuevo estado *testing*.