Versioning strategy

Versioning in Hyperon application in based on Semantic Versioning (SemVer) concept. Which means that every release is categorized as:

• Major Version change - evolution of core engines
• Minor Version change - new features, major changes in API
• Micro Version change - bug fixing (patches)

Every category has its representation in version number. Every Hyperon version is numbered with three integer values: X.Y.Z those stand for Major changes (X), Minor changes (Y) and Micro changes (Z).

In major and minor releases changes may be done within API or/and database (such as adding/removing column or table).

When such change is made within Hyperon Studio then application.properties file should contain uncommented:

#hyperon.database.autoddl-action=update

• If hyperon.database.autoddl-action value is update : everything should work properly.
• If there were any changes made to value of hyperon.database.autoddl-action property then its value should be set to update to properly load changes.
• If hyperon.database.autoddl-action property has any other value, then user should manually run database script.

Every release is published with list of implemented changes.

For minor and micro Hyperon Runtime releases :

• compiled application may be easily upgraded to newest Hyperon version by replacing old jar file with new version jar file, no need to recompile application code
• application keeps building without errors for all Hyperon non internal classes
• all Hyperon concepts remain the same, symbolic logic is kept and no great application internal process are changed

If API change is made in minor release, then backward compatible version is kept (marked as @Deprecated) for at least two more minor releases.