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

Where:

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

  <major-number>_<minor-number>
  

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

• 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-<gvsig-version>-<name>-<major-number>_<minor-number>_<revision-number>-<build-number>-<state>-src.zip

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

gvSIG-desktop-<gvsig-version>-<name>-<major-number>_<minor-number>-man-v<man-version>-<lang-code>.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.