Release notes help you decide when to update and which checks to repeat. Use the notes supplied with the exact downloaded release as the authoritative change history.
Review new customer features, fixed defects, API contract changes, dependency/toolchain requirements, migrations, and known limitations. Pay particular attention to authentication, token refresh, contact permissions, and file downloads because these can affect an existing installation even when the interface looks unchanged.
The mobile source declares its version and build in pubspec.yaml. The API module declares its version in flutex_customer_api.php. Record both when reporting a problem or planning an upgrade.
The inspected source identifies app 2.0.0+6 and API module 2.0.0. These identifiers alone do not establish a public release date or prove that every working-tree change was shipped to buyers.
Before updating, list any required configuration changes and affected customizations. Test those areas in staging and retain a copy of the release notes with the build artifacts.
If a package lacks clear release notes or a compatibility statement, request clarification through the item support channel before deploying it to a production CRM. Do not assume that a higher version number guarantees compatibility with an older mobile app or module.