GT.M Compatibility
Taking GT.M Further for the Good of the Community
The YottaDB founding team each spent over two decades working on GT.M and continue to improve the system with YottaDB, all while maintaining backwards compatibility with YottaDB and GT.M releases.
YottaDB Delivers Drop-In GT.M Compatability
YottaDB is built on the GT.M code base. GT.M is used at several of the largest real-time core-banking deployments in the world, as well as a national scale electronic health record system deployment.
When the YottaDB team creates a YottaDB release, it designs the enhancements to be backward compatible so as to ensure that existing GT.M applications can simply be upgraded to YottaDB. You can drop YottaDB into a GT.M deployment with the same confidence that you would have with a new GT.M release.
Over the years, the GT.M releases the YottaDB team created acquired a reputation among the user base for their punctiliousness in ensuring that each release was backward compatible with its predecessors.
Why Do We Know So Much About GT.M?
Each member of the founding team at YottaDB spent over twenty years working on GT.M, giving them deep and broad expertise, covering the code base, development process, product usage, performance optimization, system administration, DevOps and much more – everything that makes YottaDB rock solid, lightning fast, and secure.
A Rigorous Development Process = Easy Transitions
To engender confidence in the quality of YottaDB software – including backward compatibility with GT.M – the YottaDB development process performs extensive automated testing. Our view is that testing software to ensure the presence of desirable, correct behavior is insufficient; we must also test for the absence of undesirable, incorrect behavior, a much harder proposition.
We achieve the latter by testing for all desired, correct behaviors, even testing functionality unrelated to the software change. For every remedied defect, and for every new feature, we create automated tests to differentiate between the behavior of the software with and without the change. Software changes validate their tests and tests validate their software changes, with all software and tests 100% peer-reviewed. Both software and automated tests are version controlled (software is publicly released here and tests are publicly released here).
Every week, the current software is checked out of version control built, and tested on multiple machines across supported platforms using the current automated tests also checked out of version control. The tests randomly vary parameters to ensure that over time, all paths through the software are exercised. Any failures each week are analyzed, and tests improved or software corrected as appropriate for each test failure.
It is our experience in GT.M development and in our development processes that allows us to build software that is drop-in backward compatible with GT.M, and provide our customers with the following assurance:
Except for items identified in the release notes, if you are a YottaDB support customer and you encounter a backward compatibility issue with a YottaDB release, either with respect to its predecessor, or with respect to the GT.M version on which it is built, we will help you find a satisfactory workaround, or we will fix the issue in a new release of YottaDB.
Ready to Try YottaDB?
A Footnote on Backwards Compatibility
“Backward compatibility” applies to application functionality, and we recognize that application functionality extends beyond application code to shell scripts for DevOps and operations management. While we, in our history as YottaDB/GT.M developers, have a well-earned, decades-long reputation – don’t take our word for it, just ask our users! – for going the extra mile to ensure that you can take an existing application running on an existing version of YottaDB/GT.M, and drop in a new version YottaDB/GT.M and have the application continue to run, there are inevitably caveats in the “fine print” such as the following:
- Issue remediation is by its nature not backward compatible. Application code that expects an issue to be present, and works around it, will likely need to be reviewed.
- Application code that relies on the absence of a feature, or the value of a limit, may not run the same way when a new release adds a feature or extends a limit, and may need to be reviewed.
- Throughput and performance can change from one release to another, usually for the better. Consequently, application code that expects a certain level of performance on a certain hardware may need to be reviewed. These changes in throughput and performance may warrant application tuning to achieve optimal performance on new software releases.
- Once in a great while, on those rare occasions when we must make a change that is not backward compatible, we highlight this in the release notes. Such changes typically have two causes:
- Enhancing security often involves restricting defaults, and requiring additional authentication authorization for some feature or function previously permitted by default.
- While we always strive to design new features and functions to be backward compatible, in very rare instances a new feature may require a change such as a required environment variable or additional flag in a shell command.
- It is the nature of software that we cannot and do not guarantee our YottaDB software to be free of defects. New software may have new defects despite our best efforts. However, we support our customers by helping them work around defects, and prioritizing their needs.