Updating any software to a newer version requires users to weigh the costs associated with the update process against the value and benefits of the new features or bug fixes added – and this is no different with any of our tools. As a DevOps company, we take great care to design and release our tools through a process that permits a super-agile deployment methodology. Which allows many releases to occur in a short time frame.
In order to help ease the update process, we adhere to a fairly rigorous release numbering scheme, where each type of release has the following special considerations.
A major release has the following characteristics:
In most cases, you should schedule a specific time-slot away from crucial deployments in order to perform a major update. Many users even setup separate instances in order to explore functionality before rolling out the update to their production instance. If you choose to do this, you may use your existing license key for this purpose.
Note that you should always carefully read the upgrade notes if you do not do so already before performing a major update.
A minor release has the following characteristics:
Minor releases are typically used to add a new module or overhaul an existing one (e.g. database deployment, configuration files, variables, etc.). They are also used to add new features to the SDK (e.g. extensible agents, server hosts, etc.)
Note that you should consider carefully reading the upgrade notes if you do not do so already before performing a minor update.
A maintenance release has the following characteristics:
Maintenance releases are the lowest risk, only rarely adding new functionality and should only be updated when a specific bug fix pertains to your use. In order to validate whether these bug fixes apply to your usage scenario, make sure to view the upgrade notes before performing an update.