When should I update an Inedo Tool?

KB#1059: Last Updated February 12, 2019

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.

Major Release (3.x.x to 4.0)

A major release has the following characteristics:

  • backwards-incompatible breaking API/SDK changes are introduced which require any custom extensions to be rebuilt  against a new SDK and all extensions to be updated
  • major database schema changes
  • possible sweeping UI changes
  • major functionality updates
  • all bug fixes up to and including the new major version

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.

Minor Release (3.5.x to 3.6.0)

A minor release has the following characteristics:

  • backwards-compatible API/SDK changes are introduced
  • database schema changes
  • some functionality updates, or a new module (e.g. a new variables engine)
  • all bug fixes up to and including the new minor version

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.

Maintenance Release (3.5.7 to 3.5.8)

A maintenance release has the following characteristics:

  • bug fixes
  • no visible API/SDK changes are introduced
  • backwards-compatible database schema changes may be introduced
  • new, stand-alone features that are targeted for a future version, that may be used on a preview/beta basis; for example, the Administrative Edits in BuildMaster 4.6 were added over several 4.5.x versions, and the Maven Feeds from ProGet 3.7 were in 3.6.x versions

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.