Requirements and Recommendations

This Article outlines the Requirements and Recommendations for publishing code through LAVA onto the LabVIEW Tools Network. My Package is used as an example in throughout this Article.

Requirements
Installation Type
Code must be distributed as a package (.vip or .ogp). This will mean it is compatible with both the LabVIEW Tools Network and VIPM

Installation Directories
Installation directories have been standardized for the purpose of organisation and avoiding namespace clashes etc.
No package released on LAVA, in the LAVA-CR or elsewhere should install to these locations - only those packages that are approved by LAVA for the LabVIEW Tools Network
Once your package has been accepted, you will own that namespace and can install to other locations (if haven't already) in the future (think of it like a domain) without worry of collisions

Palettes: <vi.lib>\LAVA<\package_name>
Tools: <project>\LAVA\<package_name>
Examples VIs: <examples>\LAVA\<package_name>
Examples .bin3 files: <examples>\exbins
Addons^#: <vi.lib>\addons\_LAVA\<package_name>

^# Not for distributions that contain public VIs (i.e. VIs appear in palette or need to be linked to by end users)

Package and Palette Namespacing
Example package names will be lava_<type>_<my_package>-<version>
Where type = lib for Libraries and type=rsc for Resouces/Tools
E.g. lava_lib_my_package-1.0.0.1.vip

In VIPM the package name is directly related to the palette name
We require packages to be ordered alphabetically in the dynamic palette hence, the above convention must be followed
Additionally, if using OpenG Package Builder, palette name must match the equivalent VIPM name

VI Namespacing
It is recommended that VIs should be namespaced similar to old school VIPM renaming syntax (e.g. __lava_lib_<package_name> however, at a minimum __lava should be used
If a LabVIEW Project Library is used to namespace code instead, then add __lava namespace to the distributed library

Palette Location
Both .ogp and .vip packages that contain palette VIs will link to the LAVA Palette package as a dependency which is published on the LabVIEW Tools Network.
The palette must appear under the Addons\LAVA top level palette however, users may wish to include another palette under the correct programming sub-palette.

The VIPM Custom Category feature is currently not used

Dependencies
Any package dependencies must be also published on the LabVIEW Tools Network (aka external dependencies). Packages (especially Tools) should try to limit all dependencies by building in supporting VIs to the package (aka internal dependencies)

Coding Standards
The code distributed must meet the requirements of being LAVA Certified. Additionally you should follow the LabVIEW Development Guidelines and the standards for the Compatible with LabVIEW level that you ultimately want to achieve

Recommendations
Iconography
We recommend you use any color, glyphs, text etc... for your icons. There is no set theme or icons - we don't want to stifle your creativity!

License
We recommend that you distribute under the most flexible license to aid in end user reuse (e.g. new-BSD license), but there is no licensing requirement - only that you have one
It is recommended that this license is Open Source Initiative approved
Adding a License Agreement file is also recommended (but this requires VIPM Professional)

Premium Membership
It would be helpful if members maintained Premium Member status so they can edit and delete posts etc... to maintain their forum professionally
However, if not, we will open up this functionality for Team LAVA Developers

Folder Naming
Excluding Tools location, it is recommended that the folder name is package_name note: lower case and contains underscores for space
E.g. <LabVIEW>\vi.lib\LAVA\my_package