OpenLMIS release numbering

[Rich Magnuson]

Hi everyone,

 

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

[Kevin Cussen]

Hi Rich, 

This makes sense to me. Could I put you on for 10 minutes on the next product committee to introduce the scheme more broadly?

Cheers,

Kevin Cussen | kevin....@villagereach.org

Manager, Information Systems

 

VillageReach Starting at the Last Mile

2900 Eastlake Ave. E, Suite 230,  Seattle, WA 98102, USA

CELL: 1.206.604.4209   FAX: 1.206.860.6972

SKYPE: kevin.cussen.vr

www.villagereach.org

Connect on Facebook, Twitter and our Blog

---

From: openlm...@googlegroups.com <openlm...@googlegroups.com> on behalf of Rich Magnuson <rich.m...@villagereach.org>
Sent: Tuesday, February 2, 2016 16:16
To: OpenLMIS Dev
Subject: [openlmis-dev] OpenLMIS release numbering

 

--
You received this message because you are subscribed to the Google Groups "OpenLMIS Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/BN1PR02MB021238A8FD4E0E49CFB7EEA93D00%40BN1PR02MB021.namprd02.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

[Craig A]

Hi Guys,

There's a great spec for Semantic Versioning at http://semver.org/ It's used by a number of other open source projects in the space.

Sincerely,

Craig

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-de...@googlegroups.com.
To post to this group, send email to openl...@googlegroups.com.

[Rich Magnuson]

Hi Kevin – unfortunately, I am not certain I can make the next Product call (Feb 9, right?).  Do you think we can discuss it over the DL?

 

Craig – thanks!  I was partially inspired by semantic versioning concept.  As OpenLMIS does not seem to be as API focused or driven, I wasn’t sure how applicable SV is, but I liked the idea of x.y.patch.  Overall, I felt a more traditional (and a bit more arbitrary) scheme would be easiest to communicate.  

 

Rich

To unsubscribe from this group and stop receiving emails from it, send an email to openlmis-dev...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/6ce4f840-9ed0-4a61-9796-fff917657dc2%40googlegroups.com.

[Rich Magnuson]

Brian Taliesin  had a  related question about this over on the Product forum, so I'm cc'ing him and that group for the reply.  Hopefully it won't break email clients.  

Here's his questions:

1.      Any changes to the code should result in an increment in the patch numbering. Even if a bug is found right after posting, and it will take less time to fix the error than to create the documentation and follow the process to repost with a fix.
2.      I agree with the rubrics associated with the numbering scheme. Who decides what is a dot vs. a full release (e.g., product owner, technical committee, someone else)?

For #1:  anything pushed to master should generate an incremented release number.  In this case, it sounds like a small but critical bug fix.  This would increment the patch #.

For #2:  the decision on major/minor should rest with the tech and product groups.

Any other viewpoints?