Active and Past Releases

• 2.0.1 Release Notes
• OpenLMIS Version 2.0

Release Numbering Scheme

Starting with 2.0.0., OpenLMIS follows a basic Major.Minor.Patch release numbering scheme, e.g. 2.0.0, 2.1.3, etc.  This is influenced by the Semantic Versioning standard, but the Major and Minor numbers are incremented largely by human reckoning.  The main purpose is for levelset communication and basic project organization.  It is recognized that as OpenLMIS becomes more modular, a more sophisticated scheme may be necessary, at least at the development level (e.g. versions of core, modules, included components, etc.)

Major – number is incremented with a significant change to the application.  Examples could include a revamped modularization scheme, a UI refresh, a new sizable feature set or some break in compatibility.  

Minor – is incremented when new features or highly significant fixes are added.  May include updated developer infrastructure or updated component versions, such as supporting newer versions of Postgres  Compatibility with past releases under the same Major number is expected.  

Patch – incremented for small changes, such as important bug fixes or minor component upgrades.  Compatibility with past releases under the Major.Minor is expected.

Every push to master should increment the release number in some fashion.  For example, if OpenLMIS is at 2.1.5, a single bug fix pushed to master would change the number to 2.1.6.  Final decisions on any number change lies with the Tech and Product groups.

The version number is displayed on the login page, following the format above and includes the build number and build name.   Specifically, the form is: vMAJOR.MINOR.PATCH buildNumber-buildName, where buildNumber and buildName correspond to the name of the Jenkins build and corresponding build number.  For example, "v2.0.1 14-stable".

For discussion on this topic, see this thread.