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

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

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

···

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.

You did, thanks.

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: 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):

  • 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

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.

During our call yesterday, I briefly called out our plans for versioning. Josh sent out a
detailed explanation
on versioning within the components of the new architecture. Below is the thread. It includes a clarifying question from Kevin.

If you have questions, please feel free to respond to the original dev post or reach out to me.

Regards,

Mary Jo

···

From: openlmis-dev@googlegroups.com [mailto:openlmis-dev@googlegroups.com] On Behalf Of Josh Zamor

Sent: Tuesday, November 1, 2016 11:35 PM

To: Kevin Cussen kevin.cussen@villagereach.org

Cc: OpenLMIS Dev openlmis-dev@googlegroups.com

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):

  • 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

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,

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.

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.

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/66F442DD-0D89-49E8-84A2-FCCBAB77959B%40villagereach.org
.

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

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

···

On Wed, Nov 2, 2016 at 8:29 AM, Kevin Cussen kevin.cussen@villagereach.org wrote:

You did, thanks.

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: 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):

  • 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

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,

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.

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.

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/CY1PR02MB11191FCD294BEA191F4B3E74E3A00%40CY1PR02MB1119.namprd02.prod.outlook.com.

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

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks

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

···

On Wednesday, November 2, 2016 at 4:58:35 PM UTC-7, djazayer wrote:

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

On Wed, Nov 2, 2016 at 8:29 AM, Kevin Cussen kevin.cussen@villagereach.org wrote:

You did, thanks.

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: 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):

  • 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

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,

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.

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.

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/CY1PR02MB11191FCD294BEA191F4B3E74E3A00%40CY1PR02MB1119.namprd02.prod.outlook.com.

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

Darius JazayeriPrincipal Architect - Global Health
Email
djazayeri@thoughtworks.com

Telephone
+1 617 383 9369

ThoughtWorks