Understanding Release Notes

Where to Find Release Notes

Release notes for Project Green are published with each new version of the platform. They are typically available in the platform's documentation section, shared via email to account administrators, and posted on the internal knowledge base for Cyviz staff.

As an internal team member, you should familiarize yourself with each release before it reaches customers. This means reading the release notes promptly after they are published and understanding the key changes so you can answer questions and provide guidance.

If you are unsure where to find the latest release notes, check the internal documentation repository or ask the product team. Staying on top of releases is an important part of being effective in any customer-facing or support role.

Understanding Version Numbers

Project Green follows a versioning scheme that communicates the scope and significance of each release. Understanding this scheme helps you quickly assess whether a release contains minor fixes, new features, or significant changes that might affect customers.

A typical version number has three parts, such as 2.4.1. The first number (major) changes when there are significant architectural or breaking changes. The second number (minor) increments when new features or substantial improvements are added. The third number (patch) increments for bug fixes and small improvements that do not change existing behavior.

Knowing the version number helps you set the right expectations when communicating with customers. A patch release is unlikely to change their workflow, while a minor release might introduce new capabilities they should explore. Major releases may require customers to take action, such as updating configuration or reviewing changed features.

Communicating Changes to Customers

When a new release is deployed, customers may notice changes or receive notifications about the update. It is important that internal teams are prepared to explain what has changed and why, in language that is appropriate for the customer's technical level.

For non-technical customers, focus on the benefits of the changes rather than the technical details. Instead of saying "We refactored the alert processing pipeline," say "Alerts are now faster and more reliable." Highlight any new features that the customer might want to use and mention any changes to existing workflows they should be aware of.

For technical customers or partner administrators, you can share more detail about what was changed and how it might affect their environment. If a release includes API changes or configuration updates, make sure these are called out clearly so customers can plan any adjustments on their side.

Breaking Changes vs Enhancements

Release notes typically categorize changes into several types, including new features, enhancements, bug fixes, and breaking changes. Understanding the distinction between these categories helps you assess the impact on customers.

Enhancements and bug fixes are the most common types. Enhancements improve existing features, such as adding a new filter option to the dashboard or improving the performance of a report. Bug fixes resolve known issues that were affecting users. These changes are generally positive and low-risk for customers.

Breaking changes are less common but require the most attention. A breaking change alters existing behavior in a way that might affect customers' current workflows, integrations, or configurations. Examples include changes to the API response format, removal of a deprecated feature, or changes to alert rule behavior. When a release contains breaking changes, ensure all affected customers are informed in advance and have guidance on how to adapt.

Internal Testing Process

Before a release reaches production, it goes through an internal testing process to verify that new features work correctly and that existing functionality has not regressed. Understanding this process helps you answer customer questions about quality and reliability.

The testing process typically includes automated tests that run on every code change, manual testing of new features and bug fixes, and a staging environment where the release is deployed and validated before going to production. Internal team members may be asked to participate in testing, especially for features related to their area of expertise.

If you discover an issue during testing or after a release has gone live, report it immediately through the appropriate internal channel. Quick reporting helps the engineering team assess the severity and decide whether a hotfix is needed. Your involvement in the testing and feedback process directly contributes to the quality of the product customers receive.