Versioning, release types and support Last updated: July 2, 2024 13:51

Understanding version number

The versioning mechanism for Dwarfguard releases follows versioning scheme known from multiple other products.

The version consists of three numbers separated by the dot, like: 1.2.3 The numbers significance is:

1. First comes the major revision number
   • when new major is released, the other numbers are reset to zero (e.g. 2.0.0)
   • major represents major release, bringing significant changes and new features
   • automatic upgrade to a new major number may need manual steps (if you have installed your own server) or may even be not possible, thus requiring new application deployment. See more in upgrade types.
   • a license typically does not cover multiple major versions unless you have a high level of support or unless the old major version is marked as EOF (end-of-life in which case all paying customers of that version having valid license get free license upgrade to the new major version) or unless you are running SaaS where you do not care about your license.
   • major releases are usually less frequent than once a year
2. Second is the minor revision number
   • when new minor version is released, the patchlevel version number is set to zero (e.g. 1.8.0).
   • minor represents a regular release, bringing some new functionality.
   • minor release usually allows automatic upgrade from the previously released version (e.g. 1.8.0 support automatic upgrade from 1.7.x where x is either the last patchlevel release in the 1.7 branch or it may support direct automatic upgrade from multiple 1.7 patchlevel releases).
3. Third is the patchlevel version
   • patchlevel release brings fixes and may bring some minor functionality improvements.
   • patchlevel always support automatic upgrade from the last released version (e.g. 1.7.6 supports automatic upgrade from 1.7.5). It usually does not support upgrade from any older versions.
   • if you have valid license with at least minimum level of support, it always allows running any and all patchlevel releases in the same minor release

Releasing process

Based on the differencies between the different release types - major, minor and patchlevel release - see the chapter above - there are also differencies between the release process being followed when a new version is to be released:

• patchlevel version release
  • as this contains a limited number of fixes, the testing done covers:
    • addressed bugs fix testing
    • upgrade testing
    • deployment testing
    • basic functionality testing
  • the rest of the release process, while taking considerable time, addresses only the most needed actions:
    • support updates
    • web-page updates
    • basic materials update
    • downloadables update
    • announcements
• minor version release
  • minor version brings much more functionality than a patchlevel version, thus the scope of the testing is increased with:
    • minor new functionality testing
    • regular functionality retest (to make sure all regular functionality works as expected)
    • performance quicktest (to make sure no performance degradation was introduced)
  • the release process, while similar, may (depending on the scope) require additional actions
    • existing documentation updates
    • new functionlity/obsoleted functionality documentation updates
    • howtos
    • selected partners may be invited for a quick beta testing period
• major version release
  • major version always brings new functionality and thus not only full retesting but also new testing protocols being introduced
  • also, completely new performance testing is done and new performance protocol is released
  • major version usually calls for documentation revision including new videos and marketing material
  • there is always a beta testing period for a major release where multiple partners participate in
  • depending on the scope, later beta versions may even support upgrade to full release
  • major version release is always big and takes significant time to happen, therefore, is usually occurs once several years

Releases support

If you are running SaaS deployment of Dwarfguard, your service operator takes care of your license. If you run your own deployment of Dwarfguard, you need to manage the application version and license yourself - and in that case, the following information may be significant to your use case.

There are few phases of a release lifecycle:

1. Release is actual and supported
   • This means the release in question is the last version available and support for partners, distributors and customers using this version is provided based on what is covered by the license used for particular deployment.
2. Release is obsolete and supported
   • The version in question is still supported, but it is not last in the line. Installations running this version are recommended to upgrade to the actual version as there may be some bugs present in the obsolete version that are fixed in the actual version.
3. Release is EOL (end-of-life)
   • The version in question is no longer supported. If you run such version, you will not receive any support from Dwarf Technologies - you need to upgrade to some supported version first.
   • If you have a valid license with a support level higher than self-support (see below for support levels) for any EOL version but the license does not allow you to upgrade to any supported version, you are automatically elligible for free license upgrade - Dwarf Technologies (or a distributor you purchased/acquired the license from) will provide you with a license valid for a supported version covering at least the rest of your original license validity period free of charge. If there is no application upgrade supported from your original version to the new version, you will need to redeploy though.

Support levels and entites

Dwarfguard is usually resold by distributors (or partners). The reason for that is that Dwarf Technologies is a technological company focusing on producing the SW and taking care of high number of deployments would take time that we spend on developing products and technologies.

Therefore, the usual model of the support chain entities is one of:

1. For deployment on premise:
   • Dwarf Technologies -> Distributor -> Customer
2. For SaaS service:
   • Dwarf Technologies -> Service operator -> Customer

While the support level (for support levels definition see below) provided by Dwarf Technologies to the Distributor / Service operator is usually the same as the support level from the Distributor / Service operator to the customer, it does not necessarily need to be. Depending on the circumstances, it could be higher or lower. Also, the range of the support activities covered by a particular level does not need to be the same between different Distributors / Service operators. The description below applies to the support levels provided by Dwarf Technologies to the next support chain entity.

To inspect what support level is given to which entity:

1. In UI: review the license in the product menu System --> License Management
   • Support level (manufacturer): ... specifies support level provided by Dwarf Technologies to the Distributor/Service operator
   • Support level (distributor): ... specifies support level provided by Distributor/Service operator to the customer
2. On server commandline:
   • run /opt/dwarfg_*/licman -n -d | grep -i "support level"

Support levels description

Self-support only

• This support level is free of charge and it includes only the free services - access to the materials like documentation, troubleshooting guides and howtos published on the portal but only those resources that are open to the public. There is no guarantee of availability whatsoever and no upgrade options are included. This basically equals the no-support option provided to non-commercial deployments.
• This support level does not include the EOL-guarantee (see below).
• The free license bundled in the installation package is of this level

Non-commercial support

• Generally same as Self-support.
• Usually, the license for non-commectial usage spans over a longer time period and may contain some basic upgrade options.

Basic support

• Includes all patchlevel upgrade option for the minor version purchased during license validity period.
• Allows (usually) up to 6 months license validity.
• Allows read-only access to ticketing system.
• Contains EOL guarantee - if the last patchlevel version allowed by your license is designated as EOL during your license validity period and thus you have no option to run a supported version of Dwarfguard, you are eligible for a free-of-cost license upgrade that would allow you to deploy (or upgrade if supported) a newer, supported version of the product. The new license validity end date will not come earlier than your old license validity end date.

Standard support

• Includes EOL guarantee and all what is provided by lower support levels.
• Includes one minor version upgrade options (patchlevel unlimited).
• Allows (usually) up to 1 year of license validity.
• Allows access to ticketing system.

Advanced support

• Includes EOL guarantee and all what is provided by lower support levels.
• Includes one major version upgrade options during license validity period (minor + patchlevel unlimited).
• Allows (usuall) up to 2 years of license validity.
• Includes 30 minutes (every month) free-of-cost of on-demand support intervention.
• Lower additional on-demand support work hourly price.

Premium support

• Includes EOL guarantee and all what is provided by lower support levels.
• Any and all upgrade options included during license validity period.
• No additional limit on license length (up to 3 years which is the usual maximum).
• Guaranteed ticket response time.
• Filed tickets are highest priority.
• Includes 4 hours (every month) of on-demand support intervention (e.g. help with backup/configuration remotely on your server).
• Lowest additional on-demand support work hourly price.