This document describes the official policy regarding Eyeshot release management and the behavior of the Eyeshot proprietary file format.
Its purpose is to provide a clear reference for all customers and avoid misunderstandings.
Release Cycle
Each major version of Eyeshot (e.g., 2025) follows the same structure:
-
Beta release (20xx.0)
Published at the beginning of the cycle for evaluation and testing purposes. -
Stable releases (20xx.1, 20xx.2, 20xx.3)
Production-ready releases, each including:- Documented changelog
- List of breaking changes (if any)
- Bug fixes and incremental improvements
-
Nightly builds
Continuous builds are created between stable releases. Nightly builds contain bug fixes and improvements that will later be included in the next stable release.
Once a new stable release is published (for example, when 2025.2 becomes available), fixes are no longer applied to previous stable releases of the same major version (such as 2025.1).
In exceptional cases, and when technically possible, fixes may be backported on request to the nightly builds of older major versions still covered by the product lifecycle.
Best Practices for Using Nightly Builds
Nightly builds are primarily intended to deliver bug fixes and incremental improvements ahead of the next stable release.
- They usually contain only bug fixes, not structural changes.
- Customers are free to adopt nightly builds in production, but we recommend carefully evaluating their use case before doing so.
- For maximum stability, we suggest basing production environments on stable releases whenever possible.
Proprietary File Format
The Eyeshot proprietary file format is designed to provide backward compatibility but not forward compatibility:
- Files saved with older versions can always be opened in newer versions.
- Files saved with newer versions cannot be opened in older versions.
- Files are always saved in the current format version. Downgrading to a previous file format version is not supported.
The internal file format version is independent of the Eyeshot version and may change whenever structural modifications are required:
- Between major releases (e.g., 2024 → 2025).
- Between stable releases within the same major (e.g., 2025.1 → 2025.2).
- It does not change between nightly builds of the same stable release.
This policy has been consistent since the introduction of the proprietary file format.
For technical details, please refer to the official documentation.
Best Practices When Using the Eyeshot Proprietary File Format for Data Exchange
For customers building and distributing commercial products on top of Eyeshot and adopting the proprietary file format as their own, we strongly recommend:
-
Base your product on the last stable release of each major version (in most cases, this is the .3 release, for example 2025.3).
This minimizes the chance of file format changes within your product’s lifecycle and reduces the risk of incompatibility between minor releases of the same major. - Distribute the same Eyeshot-based version across your customers’ ecosystem to avoid incompatibility when exchanging files.
Comments
Please sign in to leave a comment.