In prep for 2.0, we got to thinking of the release numbering scheme, and would like your input on the following proposal. This scheme is used in the GitHub release tags, in documentation, Jira’s Fix Versions field, and on any future “Help-About” view in the OpenLMIS UI.
Simply put, I propose we adopt a simple major.minor.patch scheme, e.g. “2.4.15”. A brief explanation of each number position:
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 are added, significant fixes, etc. Compatibility with past releases under the same Major number is expected. May include updated developer infrastructure or updated component versions, such as supporting newer versions of Postgres
Patch – incremented for small changes, such as important bug fixes or minor component upgrades. Compatibility with past releases under the Major.Minor is expected.
What do you think? Under this scheme, the next release is 2.0.0. If we made a significant bug fix and pushed it to master, we’d have 2.0.1.
Work item OLMIS-60 covers the request to add a version file to the build output, ready for anyone to take on!
Note this is separate from whatever internal versioning scheme we may wish to adopt. Such a scheme may be more technical to accommodate versions of components, modules, etc.
Thanks - Rich