Versioning

We’ll strive to use Semantic Versionin https://semver.org/

E.g. OpenHospital 1.8.4 ↔︎ MAJOR.MINOR.PATCH

MAJOR → when we make incompatible API changes,
MINOR → when we add functionality in a backwards compatible manner, and
PATCH → when we make backwards compatible bug fixes.

Also, each component may its own version that is indipendent by other version and the release version, that it’s kept in the version.properties file.

Normally the MAJOR.MINOR numbers do reflect the core library.

E.g.

release 1.10.0 (version.properties)

• core 1.10 (pom.xml)

• gui 1.10 (pom.xml)

release 1.11.3 (version.properties)

• core 1.11 (pom.xml)

• gui 1.11.3 (pom.xml)

• api 0.1.0 (pom.xml)

• ui 0.0.1 (npm/package)

FAQ.

1. We added a new feature that needs some DB changes not breaking anything → MINOR, PATCH

2. We modified a feature to make more easy for the end user → MINOR, PATCH

3. We added a new feature that breakes the DB → x - NO WAY

   1. We have always to care about previous version by providing migration scripts

4. When we change MAJOR?

   1. Altough we strive to keep each version fully compliant with the previous ones (just adding new features, and we provide migration script between versions) “lifes goes on and… libraries change!” so it would be possible that some dependencies stop being available and breaks some features, in that case we’ll have a MAJOR bump IF we cannot workaround the problem.

   2. We are planning to release soon OpenHospital 2.0 (WIP) (core + api + ui) for which will be very hard (let’s say impossible) to make it working with the same identical libraries, hence the MAJOR version bump.