Release Notes
      Back to home
      1. Support Portal
      2. Docs
      3. Release Notes

      Understanding Dorado Software Release Versions and Numbering and Releases Cycles

      This article describes the software versioning strategy applied to software components as well as the release packages that bundle these components for distribution.

       

      Software Versioning

      Software versioning numbers play a crucial role in distinctly identifying various iterations of software, enabling developers, users, and systems to monitor changes, updates, and enhancements effectively. These version numbers typically adhere to a specific format that indicates the extent of modifications made to the software.
      For example, the current version of Cruz Software in development is v10.0.6.11. This version follows a specific numbering scheme that consists of four components: major, minor, maintenance, and build, represented as major_#.minor_#.maintenance_#.build_#. In this instance, the version breakdown is as follows:

      - Major version: 10

      - Minor version: 0

      - Maintenance version: 6

      - Build version: 11

      Major version: This number increases when there are backward-incompatible changes, often referred to as breaking changes or redesigns. It signifies substantial alterations or the introduction of new features that can affect existing functionality by removing or replacing current features. Examples of such changes may include:

      - Significant modifications to the database structure, necessitating new or custom development for users to upgrade to the new version.

      - Changes to foundational components that require extensive integration efforts.

      - The addition of major new features or functionalities that enhance the software’s capabilities.


      Minor version: This number increases when new features or improvements are added without breaking backward compatibility. It signifies enhancements or smaller changes, such as the introduction of new functionality that enhances user experience or performance without altering existing features. For example, adding a new reporting tool or improving the user interface can be classified as minor version updates. These updates often include optimizations that improve speed or reduce resource consumption, as well as minor tweaks that refine usability based on user feedback. Importantly, users can upgrade to these versions without the need for significant changes to their existing systems or workflows, ensuring a smooth transition and continued functionality. Overall, the minor version serves as an essential indicator of ongoing development efforts aimed at enhancing the software while maintaining stability and compatibility for users.


      Maintenance version: This number increases when bug fixes or small improvements are made that do not introduce new features or break compatibility. The maintenance version is essential for ensuring the stability and reliability of the software, as it addresses issues that may affect performance or user experience without altering the core functionality. Typical updates in this category include resolving bugs that could lead to crashes, fixing security vulnerabilities, or correcting minor inconsistencies in the software's operation. Additionally, maintenance updates may involve performance enhancements that optimize existing features, ensuring the software runs more efficiently. Users can confidently apply these updates, knowing that their current workflows will remain intact, and they will benefit from improved stability and security. The maintenance version is a key aspect of ongoing software support, reflecting the commitment of developers to provide a robust and dependable product over time.

      Build versions: This number increases when a new component or package is built in the development environment. The build version serves as a unique identifier for each compilation of the software, reflecting the ongoing development process and any incremental changes made during that phase. 

      Each build represents a snapshot of the software at a specific point in time, capturing the state of the codebase after changes, bug fixes, or optimizations have been applied. This allows developers to track the evolution of the software, facilitating easier debugging and testing. For example, if a particular build introduces a bug, developers can quickly reference the build number to pinpoint the changes made since the last stable version, aiding in efficient troubleshooting and resolution.

      Release Cycles

      The software release cycle for Generally Available (GA) versions is flexible and influenced by two primary factors: the internal product development roadmap and customer demand for enhancements or maintenance updates. Typically, the release schedule is as follows:

      - Major releases are designated as GA once a year.

      - Minor and maintenance releases are made GA 2 to 4 times annually, with an aim to achieve at       least one release each quarter.

      - Build or component releases may occur at any time to address defects, security vulnerabilities,      or implement very minor enhancements. These are typically provided to specific affected                 customers and also available to others on request.