Personal tools
You are here: Home gvSIG Projects gvSIG Desktop Documentation Developers documentation How to contribute in gvSIG? gvSIG official projects Naming binaries for a gvSIG plugin
gvSIG Desktop
gvSIG Desktop

Cached time 11/21/13 11:24:39 Clear cache and reload

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


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.

  • 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:


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



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

change log
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.

Powered by Plone CMS, the Open Source Content Management System

This site conforms to the following standards: