OpenLMIS release numbering

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

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.cussen@villagereach.org

Manager, Information Systems

Village****Reach 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: openlmis-dev@googlegroups.com openlmis-dev@googlegroups.com on behalf of Rich Magnuson rich.magnuson@villagereach.org

Sent: Tuesday, February 2, 2016 16:16

To: OpenLMIS Dev

Subject: [openlmis-dev] OpenLMIS release numbering

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

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+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@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
.

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

···

On Tuesday, February 2, 2016 at 4:44:01 PM UTC-8, Kevin Cussen wrote:

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

Village****Reach 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

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

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-de...@googlegroups.com.

To post to this group, send email to
openl...@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
.

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

···

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

On Tuesday, February 2, 2016 at 4:44:01 PM UTC-8, Kevin Cussen wrote:

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

Village****Reach 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

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

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-de...@googlegroups.com.

To post to this group, send email to openl...@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
.

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+unsubscribe@googlegroups.com.

To post to this group, send email to
openlmis-dev@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
.

For more options, visit https://groups.google.com/d/optout.

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?

···

On Tuesday, February 2, 2016 at 4:16:33 PM UTC-8, Rich Magnuson wrote:

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