Hop til hovedindhold

Releases & Planning

Document status35 - Reviewed

Versioning Strategy

EnergyConnect employs a dual-layer versioning strategy to clearly distinguish between external product releases and internal technical changes. This approach allows us to communicate effectively with both business stakeholders and technical teams.


Commercial Versioning

Commercial versioning represents the externally visible release label used in product communication, marketing materials, and user-facing documentation.

  • Format: EnergyConnect X.Y
  • Definition:
    • X – Major commercial release number (e.g. EnergyConnect 3)
    • Y – Optional minor commercial update (e.g. EnergyConnect 3.1)

Commercial version numbers are incremented based on business and product management decisions. They signal the introduction of notable new capabilities or strategic milestones rather than strictly reflecting underlying code changes.

Example:
EnergyConnect 3.1 might internally correspond to semantic versions like 3.1.0, 3.1.2, or 3.1.5.
The move from EnergyConnect 3 to EnergyConnect 4 is a business-driven decision and does not necessarily align with semantic versioning thresholds.


Semantic Versioning

Internally, EnergyConnect follows Semantic Versioning to manage the evolution of the codebase in a predictable and consistent way.

  • Format:
    MAJOR.MINOR.PATCH

Where:

  • MAJOR – Introduces breaking API or platform changes requiring consumers to update their code or configurations.
  • MINOR – Adds backwards-compatible features or enhancements without breaking existing functionality.
  • PATCH – Delivers backwards-compatible bug fixes or security patches.

This versioning layer enables development teams to track compatibility and manage dependencies accurately during the software lifecycle.


Guidance on Updating

To ensure stability, security, and access to the latest improvements, consumers are encouraged to stay current within their supported release line:

  • Patch updates (PATCH):

    • Contain only bug fixes and security updates
    • Low risk and should be applied promptly
  • Minor updates (MINOR):

    • Introduce new functionality in a backwards-compatible way
    • Generally safe, though validation in staging environments is recommended
  • Major updates (MAJOR):

    • May contain breaking changes
    • Require thorough testing and planning before adoption

Release notes detailing all significant changes, deprecations, and migration steps are published internally for each release.

Note:
It is strongly recommended to perform comprehensive testing when adopting a new version to verify compatibility and prevent potential regressions.