TatukGIS menu


Release schedule

TatukGIS uses an automated build server which helps to automate the build process of our programs. Each build can have one of three states:

  • We build TatukGIS software each night.
  • NIGHT builds are generally available only for TatukGIS internal purposes, but from time may be shared with selected customers for bug fix verification purposes.
  • Typically an UNSTABLE build is released each Friday, but with some flexibility. We may skip a week if progress is not sufficient and there is nothing interesting to show.
  • An UNSTABLE version can be released sooner than each Friday in the event of an important bug fix.
  • UNSTABLE builds are available to all customers (licensed users) of the software product with active maintenance. UNSTABLE builds do not contain any trial version. Free software products like the Viewer and Coordinate Calculator are not released as UNSTABLE builds.
  • UNSTABLE builds contain the latest progress with new features, performance improvements, bug fixes... The latest changes introduced in UNSTABLE builds may not be fully tested. An UNSTABLE build is not necessarily unstable, but it could be :)
  • STABLE builds are typically released on a Friday after approximately four weeks of UNSTABLE builds - typically in the second half the month.
  • STABLE builds can be released sooner in the event of urgent bug fixes.
  • If is nothing new is ready to offer (new features, important bug fixes), the next STABLE build can be delayed until there is something of interest to share. (The Coordinate Calculator product, for example, is not updated often.)
  • STABLE builds are full, official builds that include a trial version for evaluators.
  • Our general suggestion is to use STABLE versions unless you are anxious for quicker access to fixes and features provided in an UNSTABLE version.

This release schedule is only a general plan, and should not be interpreted to be any sort of TatukGIS obligation.

Reading version numbers

Suppose you have a version How to interpret it? Version numbers should read as major.minor.release.build, in which:

  • Major (10)
    Major version number. A new number here indicates a major new version (new generation) of the software.
  • Minor (12)
    Minor version number. This number is reset to 0 upon each new major version release. Each incremental increase in this number indicates the version introduces some new features.
  • Release (1)
    Release version. This number is reset to 0 upon each new minor version release. Incremental increases in this number indicate that no new features were introduced.
  • Build (12542)
    Build number. This is our generation number that is used to uniquely identify each released version in our subversion archive (so we know exactly which source code was used to build it). Yes, this means that the major, minor, and release numbers, in fact, are only a logical naming scheme used to intuitively classify each version
Posted: September 24, 2013