You did, thanks.
···
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: Josh Zamor
Sent: Tuesday, November 1, 2016 23:35
To: Kevin Cussen
Cc: OpenLMIS Dev
Subject: Re: [openlmis-dev] Versioning post-Beta
Hi Kevin, what you outlined sounds correct. There are 4 types of Versioned components in the new architecture (not counting the Reference Distribution):
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
On Nov 1, 2016, at 2:31 PM, Kevin Cussen kevin.cussen@villagereach.org wrote:
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,
–
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/CY1PR02MB1119834D4629B57912D9C640E3A10%40CY1PR02MB1119.namprd02.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.
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 Josh Zamor josh.zamor@villagereach.org
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 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
–
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/8cbcbb6b-7f8c-477d-82ed-768bfda651d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
