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-<gvsig-versión>-<name>-<major-number>_<minor-number>_<revision-number>-<build-number>-<state>-<platform>.<zip|exe|bin>

Donde:

• gvsig-versión es el número de versión de gvSIG, en el formato de:

  <major-number>_<minor-number>
  

  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).

• 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-<gvsig-version>-<name>-<major-number>_<minor-number>_<revision-number>-<build-number>-<state>-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-<gvsig-version>-<name>-<major-number>_<minor-number>-man-v<man-version>-<lang-code>.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.