ReleasePolicy

Versioning

Clear, unambiguous and predictable semantic versioning ensures that everyone, including server hosters and end-users, knows how and when new features/functionality, fixes, and breaking changes effectively arrive.

The version number for a new release will always be set just before creating that release and will be determined in accordance with semantic versioning. To put it simply, version numbers will be of the form major.minor.patch:

• MAJOR version when you make radical changes breaking compatibility between components.
• MINOR version when you add functionality, yet backwards-compatibility is maintained (e.g. UI changes).
• PATCH version when you make minor bug fixes or small tweaks — with compatibility undisturbed.

---

• If there are no incompatibilities with other components, the patch version from the previous release will be incremented.
• If there are UI changes or additions, yet no incompatibilities with other components, the minor version from the previous release will be incremented and the patch version set to 0.
• If there are incompatibilities with other components, the major version from the previous release will be incremented and the minor and patch versions set to 0.

Note

.PATCH segment may be omitted if it tantamounts to zero (You may still see it though in some versions).

Server Versioning

Server versioning is entirely identical - though with one subtle nuance:

Important

Regarding server versioning, a server version which maintains compatibility with the clients - yet breaks backwards-compatibility - with previous ermis-server versions will be denoted with a -C flag in the version (e.g server-v1.5.6-C) standing for CAREFUL.

Release Components

Each constituent is shipped individually:

• Server
• Desktop Client
• Mobile Client

Effectively, each component gets its own version release independently in accordance to the rules above — except when bumping to a MAJOR version. A major bump always applies to all components without exception, since it signals/denotes/signifies a major compatibility break.

When to Bump Each Segment

1. Patch
   Minor bug fixes; no component incompatibilities.

   Increment the previous release’s patch number.

2. Minor
   Adds UI tweaks or new features without breaking compatibility.

   Increment the previous release’s minor number, reset patch to 0.

3. Major
   Introduces breaking changes or incompatibilities with other components.

   Increment the previous release’s major number, reset minor and patch to 0.

Example Workflow

1. You fix a UI bug (e.g you fixed out of bounds buttons in a dialog by adding width constraints to their encompassing containers) in the Mobile client →
   Bump client-mobile-v1.0.1 → client-mobile-v1.0.2
   (Server remains at server-v1.0.1, Desktop Client at client-desktop-v1.0.0)

2. You add a non-breaking brand new screen to Desktop Client →
   Bump client-desktop-v1.0.0 → client-desktop-v1.1.0

3. You refactor the server, and now incompatibilities emerge in the clients →
   Bump ermis-release-1.0 → ermis-release-2.0 (Server, Desktop, Mobile)

Release Notes & Documentation

Every release is documented (More or less) in the GitHub Releases page with a:

• Brief overview
• Change log (new features, fixes, breaking changes)
• Source Code