:Version: 1.5

Before discussing file names for the distribution, the following information is required:

- The short name or code of the plugin.

- The version number of the distribution. Read the document `Interpreting the gvSIG version number`_ to familiarise yourself with gvSIG version numbers.

- The platforms for which the distribution will be built.

- The status of the development: alpha, beta, RC, final, ...

- The version of gvSIG for which it will be packaged.

Once this information has been collected, the file naming criteria for the distribution can be reviewed.

The first criterion is that the entire file name must be in *lower case*.

The format to use for the name is as follows::

  gvSIG-desktop---__---.

Where:

- *gvsig-version* is the gvSIG version number specified in the following format::

  _

  Neither the revision nor the build number is specified as no changes to the API are expected between versions.

- *name* is the project's short name or code.

- *major number*, *minor-number*, *revision-number*, and *build-number* identify the version of the project. Depending on the gvSIG version for which the extension will be published, we advise to use a different *major-number* as well. E.g., if the extension is available for gvSIG 1.x as well as gvSIG 2.x, the extension's *major-number* could be set to *1* and *2* respectively. The important thing is for them to be different to avoid confusion, not to be the same numbers as the gvSIG ones.

- *state* can be:

  - *devel*, for versions under development.

  - *pilot*, for pilot plugins. Pilots are usually made available for testing, don't have full functionality and might contain bugs.

  - *prototype* indicates a *proof of concept* that shows how developers plan to undertake a development. Future developments might not necessarily follow the same track.

  - *testing* is used for versions that need to be tested prior to moving to *alpha*, *beta*, etc., stages.

  - *alpha*.

  - *beta*.

  - *RC* followed by a number (*RC1*, *RC2*, ...) identifies release candidates prior to the final version of the product.

  - *final* identifies the *final* version of the plugin.

  A development doesn't have to go through each of these stages but the distribution state should be specified.

- *platform* contains information about:

  - The system on which the development runs, *windows*, *linux*, *mac* or whether it is system independent.

  - The hardware architecture.

  - The minimum version of the java virtual machine required.

  These could be one of the following:

  - *all-all-j1_5*, for binaries compiled for Java Virtual Machine version 1.5.x that are independent of the system and hardware architecture.

  - *all-all-j1_6*, for binaries compiled for Java Virtual Machine version 1.6.x that are independent of the system and hardware architecture.

  - *win-i586-j1_5*, for *MS Windows* binaries compiled for Java Virtual Machine version 1.5.x.

  - *win-i586-j1_6*, for *MS Windows* binaries compiled for Java Virtual Machine version 1.6.x.

  - *lin-i586-j1_5*, for *linux* binaries compiled for Java Virtual Machine version 1.5.x.

  - *lin-i586-j1_6*, for *linux* binaries compiled for Java Virtual Machine version 1.6.x.

  - *mac_10_4-i586-j1_5*, for *Mac OS* version 10.4 binaries compiled for the Java Virtual Machine that includes the base for that version of Mac (java 1.5).

.. warning::

   The platform identifier *"i586"* is being evaluated and an alternative that better identifies the platform is being considered. While most identifiers currently distinguish between 32 bit and 64 bit architecture rather than between i586_ or i686, we propose using x86_ and 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

- With respect to extensions, the following are used:

  - *exe* for *MS Windows* installables.

  - *bin* for Linux installables.

  - *zip* for Mac installables and multi-platform versions.

For source distributions the format will be::

  gvSIG-desktop---__---src.zip

Finally, when distributing formatted versions of the documentation these should be in PDF format and should be named as follows::

  gvSIG-desktop---_-man-v-.pdf

Where:

- *man-version* is the version number of the manual. It is possible that multiple versions of the manual might be generated for a specific version of the product. Normally the version of the manual that is made available at the product's initial distribution is enhanced during the following weeks or months. Updated versions of the manual are then published without recreating a new distribution of the application.


- *lang-code* identifies the language the manual is written in. ISO639_ *Alpha-2 code space* codes should be used for these wherever possible.

For source distributions and documentation no distinction is made between platforms.

.. _ISO639 : http://en.wikipedia.org/wiki/ISO639
.. _`Interpreting the gvSIG version number` : /web/reference_catalog/lookupObject?uuid=99467e3828f3fe1a25ef5b6c96d17a13

.. list-table:: change log
   :header-rows: 1

   * - version
     - description
  
   * - 1.1
     - Added *gvsig-version*.
     
   * - 1.1
     - Added the *status*.
     
   * - 1.2
     - Corrected a formatting error. The location of the *state* was incorrect.
     
   * - 1.3
     - Added *devel* as an option for state.
     
   * - 1.4
     - Changed the literal *gvSIG* at the start of the file name to *gvSIG-desktop* and modified the  platform support to *all*.

   * - 1.5
     - Substituted *status* with *state* and added a new state *testing*.