Versioning post-Beta

9 views
Skip to first unread message

Josh Zamor

unread,
Nov 1, 2016, 5:08:52 PM11/1/16
to OpenLMIS Dev
Hi all,

This is a quick note about versioning now that Beta has been released.  As we saw in the last showcase, components are now versioned, and I level-set all components shipping in 3.0.0-Beta at the same "3.0.0-beta" version in the hope that it would be easier to talk about the version we are working on.

What may not be clear is that the releases we talk about at a product level (Beta, 3.0, 3.1, 3.2, etc) are for the Reference Distribution currently residing at openlmis-blue.  Each component (Service, Reference UI, Extension Module, etc) that makes up the Reference Distribution may be versioned and released independently.  An example of how this could have worked for the Beta release:  the Notification Service hasn't seen much activity recently, and in fact nothing changed in this service for a few weeks before the Beta release at the end of October.  It appears that this service was ready to be a stable release on it's own (perhaps as Notification v3.0) prior to the official Reference Distribution Beta release.  This is something we could have done were we ready, though for Beta we weren't quite there.

The ability for various components to progress and be released independently is a goal of the re-architecture.  Those responsible for a component should be able to plan their component's releases (beta, stable, etc) independently and in accordance to the contract that they provide to their clients.  Similarly the Product Owner and the OpenLMIS community will pull in component releases when a new Reference Distribution release is in progress.

Moving forward not all new components need to start at 3.0, and for brand new functionality I'd recommend that those components work toward a 1.0 release.  Next time a new repository or component is created, SolDevelo and VillageReach should talk about its version in order to make a purposeful decision.

If you have a question about how this will work, please ask.

Best,
Josh

Kevin Cussen

unread,
Nov 1, 2016, 5:31:36 PM11/1/16
to OpenLMIS Dev

Hi Josh,


Thanks for the explanation. Let me see if I understand what you've wrote. Each quarterly release of the OpenLMIS reference distribution will consist of many components that will each have their own version. So, for example, you could have:


OpenLMIS 3.1 containing

Reference UI 3.0

Notifications service 3.1

Inventory Management 1.0

Vaccines 0.9

Etc.


If this is correct, will we be publishing this "table of contents" information in our release notes moving forward?


As we progress, will the reference distribution support only one version of each component or a range? How will the community be made aware of support and interdependency?


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 Josh Zamor <josh....@villagereach.org>
Sent: Tuesday, November 1, 2016 14:08
To: OpenLMIS Dev
Subject: [openlmis-dev] Versioning post-Beta
 
--
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/8cbcbb6b-7f8c-477d-82ed-768bfda651d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Josh Zamor

unread,
Nov 2, 2016, 2:35:11 AM11/2/16
to Kevin Cussen, OpenLMIS Dev
Hi Kevin, what you outlined sounds correct.  There are 4 types of Versioned components in the new architecture (not counting the Reference Distribution):

- Independent Service
- Service’s Extension Modules “partner images"
- Extension Modules
- Reference UI Module

When a version of the Reference Distribution “ships”, it specifies which version of each Service, Reference UI Module and Extension Module “partner image” it includes (the latter is a WIP).  In this way the Reference Distribution is just a “sum of all parts” and I don’t think it would make much sense for the Reference Distribution itself to declare that it supports a range of versions for any one particular component.  

From the perspective of a Service depending on another Service however, I would say that is an area we’re not currently investing a lot of energy into as we haven’t encountered the need to.  We are however setting ourselves up for handling that need when it arises.  e.g. presently Services have an api-endpoint that reports the name of the service and the version deployed along with other useful build information that a client service could use to determine if the deployed component meets its needs.  Further, specific components such as Extension Modules will be deployed and consumed via Maven, which already supports declaring dependent version ranges as you described.  And finally all components are following Semantic Versioning which helps a client understand what to expect out of a version change.  All other solutions aside, each component should at the very least declare the other components it depends on as well as the version in its README - this is an easy thing I think we could improve on today.

For future release notes a “table of contents” for the components that are included and their versions sounds like a great idea.  For the previous release, as noted, we really only needed to say “3.0.0-beta” as everything was level-set for that release.

Did this answer your questions?

Best,
Josh



What may not be clear is that the releases we talk about at a product level (Beta, 3.0, 3.1, 3.2, etc) are for theReference Distribution currently residing at openlmis-blue.  Each component (Service, Reference UI, Extension Module, etc) that makes up the Reference Distribution may be versioned and released independently.  An example of how this could have worked for the Beta release:  the Notification Service hasn't seen much activity recently, and in fact nothing changed in this service for a few weeks before the Beta release at the end of October.  It appears that this service was ready to be a stable release on it's own (perhaps as Notification v3.0) prior to the official Reference Distribution Beta release.  This is something we could have done were we ready, though for Beta we weren't quite there.


The ability for various components to progress and be released independently is a goal of the re-architecture.  Those responsible for a component should be able to plan their component's releases (beta, stable, etc) independently and in accordance to the contract that they provide to their clients.  Similarly the Product Owner and the OpenLMIS community will pull in component releases when a new Reference Distribution release is in progress.

Moving forward not all new components need to start at 3.0, and for brand new functionality I'd recommend that those components work toward a 1.0 release.  Next time a new repository or component is created, SolDevelo and VillageReach should talk about its version in order to make a purposeful decision.

If you have a question about how this will work, please ask.

Best,
Josh

-- 
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/8cbcbb6b-7f8c-477d-82ed-768bfda651d7%40googlegroups.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...@googlegroups.com.
To post to this group, send email to openlm...@googlegroups.com.

Kevin Cussen

unread,
Nov 2, 2016, 11:29:51 AM11/2/16
to OpenLMIS Dev

You did, thanks.


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: Josh Zamor
Sent: Tuesday, November 1, 2016 23:35
To: Kevin Cussen
Cc: OpenLMIS Dev
Subject: Re: [openlmis-dev] Versioning post-Beta
 

Darius Jazayeri

unread,
Nov 2, 2016, 7:58:35 PM11/2/16
to Kevin Cussen, OpenLMIS Dev
Now that I read this, I realize there's one thing we're going to need to add to the implementation of Extensions. An extension should be able to declare which versions +/- version ranges of a service it works with. And the service should throw errors if you try to load an incompatible extension.

E.g. our hypothetical CustomOrderQuantityAlgorithm extension to the requisition service could say that it requires requisition 3.2+.

-Darius

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
Connect on Facebook, Twitter and our Blog


Sent: Tuesday, November 1, 2016 14:08
To: OpenLMIS Dev
Subject: [openlmis-dev] Versioning post-Beta
Hi all,

This is a quick note about versioning now that Beta has been released.  As we saw in the last showcase, components are now versioned, and I level-set all components shipping in 3.0.0-Beta at the same "3.0.0-beta" version in the hope that it would be easier to talk about the version we are working on.

What may not be clear is that the releases we talk about at a product level (Beta, 3.0, 3.1, 3.2, etc) are for theReference Distribution currently residing at openlmis-blue.  Each component (Service, Reference UI, Extension Module, etc) that makes up the Reference Distribution may be versioned and released independently.  An example of how this could have worked for the Beta release:  the Notification Service hasn't seen much activity recently, and in fact nothing changed in this service for a few weeks before the Beta release at the end of October.  It appears that this service was ready to be a stable release on it's own (perhaps as Notification v3.0) prior to the official Reference Distribution Beta release.  This is something we could have done were we ready, though for Beta we weren't quite there.

The ability for various components to progress and be released independently is a goal of the re-architecture.  Those responsible for a component should be able to plan their component's releases (beta, stable, etc) independently and in accordance to the contract that they provide to their clients.  Similarly the Product Owner and the OpenLMIS community will pull in component releases when a new Reference Distribution release is in progress.

Moving forward not all new components need to start at 3.0, and for brand new functionality I'd recommend that those components work toward a 1.0 release.  Next time a new repository or component is created, SolDevelo and VillageReach should talk about its version in order to make a purposeful decision.

If you have a question about how this will work, please ask.

Best,
Josh

-- 
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.

-- 
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.

--
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 openlm...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/CY1PR02MB11191FCD294BEA191F4B3E74E3A00%40CY1PR02MB1119.namprd02.prod.outlook.com.

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



--

Darius JazayeriPrincipal Architect - Global Health
ThoughtWorks

Josh Zamor

unread,
Nov 7, 2016, 4:55:27 PM11/7/16
to OpenLMIS Dev, kevin....@villagereach.org
Good point Darius,

I've added an issue (a stub presently) into the backlog for this:  https://openlmis.atlassian.net/browse/OLMIS-1331

Thanks,
Josh
Reply all
Reply to author
Forward
0 new messages