16.5 Past Release Version Backward Compatibility

TUFLOW uses a unique software build identifier to track and manage new versions of the software. This identifier has changed format in the TUFLOW 2025 release. From the 2025 release and onwards, version numbering will use the year.minor.patch convention. The year corresponds to the major version number e.g. this release is 2025.0.0. Major releases are the only releases that will admit the possibility of implementing changes to defaults, making other breaking changes or affecting backwards compatibility. Advice will be provided on this in corresponding changelogs (e.g. the 2025.0.0 Backward Compatibility Section). Throughout the year, additional minor releases (releases containing new features and bug fixes, but no breaking changes) would increment the minor version number (e.g. 2025.1.0) and bug fix only releases would increment the patch version number (e.g. 2025.0.1). Previously, the versioning system used year-month-xx-precision-bitOS where ‘xx’ was the two letters starting at AA then AB, AC, etc. For precision, iSP = single precision, iDP = double precision.

The build number is written to the first line in the .tlf log files so it is clear what version of the software was used for a simulation. For example:

 Build: 2025.0.0-iSP-w64

Advances in science, subsequently built into new release versions may cause slight result differences from one release version to another. In recognition of this, if a project is completed using a specific version of the software, continued future use of that software version for that particular model is recommended to achieve identical results.

During the life of TUFLOW, every effort has been made to provide full backward compatibility to past release versions. Chapter 18 lists code changes that may cause a change in model result. If a legacy or old model is being upgraded to the latest TUFLOW release, it is recommended that you familiarise yourself with possible changes to the default settings that may change results, and make the necessary changes as appropriate. In nearly all cases a backward compatibility switch is provided so that new builds can reproduce past build results (see Defaults). In rare cases exact byte identical replication of a past build result may not be possible using a new release version because different compiler versions were used to create the respective executables.