Versioning of the Open Source Desktop Client

Repository Branches

We use Git branches and tags to organize changes that are made during development.

The open-source repository is a fork from our internal one which contains the parts of code that is related to Desktop Client. It evolves daily and incorporates every change that our developers make in certain versions. 

Additionally, it inherits the main VMS release and development cycle replicating the main branches. 

There are three types of branches in the Open Source Components repository:

• Develop (master) - contains the most up-to-date changes for the upcoming version. On the other hand, the code there is less stable.
• Major Release (e.g. vms_5.0, vms_5.1) - branches that contain commits from the Master branch up until a point we do an official release.
  • The current VMS releases are built from the corresponding branches so these commits are reviewed and tested. Those are the most stable branches. Only critical fixes are pushed and only for the latest release version. We provide only a few latest release branches and encourage updating to the latest official release.
  • The upcoming releases are built from such branches too. These branches have much more active development so they are less stable.
• Hotfix Release (e.g. vms_5.1.1) - created from the Release branches and contains fixes which are released as regular updates after the official release. Less stable than the branches for the official released versions. Since we support the latest released version, we provide patches for this version only.
• Patch (e.g. vms_5.1_patch) - created from the Release branches and contain fixes which are intended to fix certain customer issues. Less stable than the branches for the official released versions. Since we support the latest released version, we provide patches for this version only. At some point, certain fixes are accumulated and pushed to the next Hotfix Release.

The development cycle looks like the following:

I.e. if 5.1 is the last official release, then 

• vms_5.0, vms_5.0 - current VMS release branches (the most stable)
• vms_5.0 - the latest release: only critical fixes are pushed
• vms_5.0_patch is not developed
• vms_5.1_patch is less stable than the release but still under development (bug fixes)
• vms_5.1.1 is stable Hotfix Release
• vms_6.0 - upcoming release under active development (even less stable)
• master - contains the most recent changes, but the most unstable.

If applicable, changes that are made in the current release branch (i.e. vms_5.1) are grafted to:

• the corresponding patch branch (vms_5.1_patch)
• The hotfix branch (vms_5.1.1)
• the upcoming release branch (vms_6.0)
• master.

Additionally, we use tags to identify the particular commits that are compatible with the Server version released and available for downloads (see “Client-Server Compatibility” below).

Versioning

Version is the key component of the distribution management. The version is passed to the binary files and distributions during the build process.

The format is `X.Y.Z.ABCDE`, where:

• X.Y.Z - Major/Minor Version that is automatically taken from the source code depending on the branch. For instance, it is `5.0.0` in the `vms_5.0` branch and `5.1.0` in the `vms_5.1` branch

ABCDE - build number. Identifies the particular build within the version. This value is determined during the configuration stage and is equal to the compatible Server.

Client-Server Compatibility

The Desktop Client can connect to Servers if they have the same Brand and Protocol Version.

Brand Compatibility

Brand Compatibility is determined by the Customization Package (the Cloud Portal it is made from). 

By default, the default customization package is downloaded as a dependency while building the project. This package works with Nx Meta Server and Nx Meta Cloud Portal.

A custom package can be made from a Cloud Portal and will be compatible with this Cloud Portal and the corresponding Server. 

See "Obtaining Customization Package for the Open Source Desktop Client".

Protocol Version Compatibility

Compatibility is guaranteed only for Open-Source Desktop Client built from the same commit as the Server:

• Master - no compatible servers available at the moment
• Upcoming releases - compatible with the Meta intermediate releases which can be identified by tags (i.e. vms/5.1/35151_beta_meta_R1).
• Current VMS releases/Patches - compatible with the corresponding release versions. We maintain compatibility within the same release and patch.

I.e. if 5.0 is the last official release, then: 

• vms_4.2, vms_4.2_patch - will be compatible with the last released 4.2 version or with the last released 4.2 patch.
• vms_5.0, vms_5.0_patch - will be compatible with the last released 5.0 version or with the last released patch.
• vms_5.1 - will be compatible with the:
• VMS Beta versions according to tags: vms/5.1/35152_beta will be compatible to the Beta version of the corresponding brand (build 35152)
• Meta releases according to tags: vms/5.1/35151_release_meta_R1 will be compatible to Meta R1 Release (build 35151)
• master  - vms/5.2/35653_release_meta_R11 will be compatible to Meta R11 Release build 35151

We recommend working with tags.

Open-Source Desktop Clients built from further commits in the same branch may retain compatibility with the publicly released Nx Meta Server for a while, but will eventually lose compatibility due to how changes are introduced synchronously into different parts of the source code.

See also “Obtaining a correct Server to run with the Open-Source Desktop Client”.