Requisition service 3.1.3 release request

[Sebastian Brudziński]

Hello everyone,

the Malawi team has recently contributed a change to the requisition service that allows service-level tokens to retrieve data for certain endpoints. This is a change that is required by our custom reports and those endpoints are used from our custom module. Unfortunately, we cannot work on a snapshotted version of the requisition service as it also brings the changes required to the latest reference data (with orderables refactor) for which we are not ready just yet and which won't work with ref data 5.0.0. Would it be possible to have the Requisition service 3.1.3 release, containing just the changes up to enabling service-level tokens? 

Regards,
Sebastian Brudzinski.

--

Sebastian Brudziński
Software Developer / Team Leader
sbrud...@soldevelo.com

SolDevelo Sp. z o. o. [LLC]
Office: +48 58 782 45 40 / Fax: +48 58 782 45 41 Al. Zwycięstwa 96/98 81-451, Gdynia
http://www.soldevelo.com

Place of registration: Regional Court for the City of Gdansk KRS: 0000332728, TAX ID: PL5862240331, REGON: 220828585, Share capital: 60,000.00 PLN

[Paweł Gesek]

Hello,

I know that we didn't want to worry about inter-service dependencies for now, but I believe this case highlights a real issue - a PATCH change in requisitions requires a MAJOR update to reference data. For implementations, the reality is that this is not a PATCH change, it is a MAJOR change - the requisition version means very little here.

I think that we should start thinking about this - it would be easy to hack up a solution that gets the version of the reference data and makes the call based on its version - until we deprecate support.

Going through the bing bang release with reference data might also be a solution that makes this problem go away - but it won't eliminate it completely.

What does everyone else think?

Regards,
Paweł

--
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/fa5a267e-9db9-2214-d480-8050907e4e7d%40soldevelo.com.
For more options, visit https://groups.google.com/d/optout.

--

Paweł Gesek
Technical Project Manager
pge...@soldevelo.com / +48 690 020 875

[Paweł Albecki]

Hi,

What Paweł said make a lot of sense. First of all, each microservice version should make it clear what version of a different microservice it require and when there are some breaking changes in other microservices that require changes in the microservice, we should consider if the microservice SNAPSHOT version (future release) still needs to supports old version of dependent microservice. The best solution here is not producing breaking API changes or think about supports for graceful failures (fault tolerance).

Best Regards,

Paweł

[Josh Zamor]

The patch release for Malawi didn't find a problem in semantic versioning that I can see.  Requisition Service was working on v3.1.3, which had a planned dependency on Reference Data v6.0.0.  For Malawi they suddenly needed a Requisition v3.1.3 that worked with Reference Data v5.0.1.  This was outside of the working plan for v3.1.3.  While we were able to accommodate that, it should be clear that we don't want to encourage this - we cut down on what I believe is significant overhead when we have a simple plan and we stick to it.  This release cycle was only a sprint long after-all.

We've stayed away from building a custom tool to detect another Service's version as it doesn't feel like it'll have much benefit at the moment.  I still feel that way, as such a tool wouldn't have told us anything we didn't already know in this instance.  I do think Service's should provide a list of the dependent services+version they expect to work with - likely in the README.  I also feel that aside from the decision we've made in Reference Data to do a "big bang" release to get search endpoints paginated and supporting extra data's POST operation, we generally should prefer to not break contracts - that is don't try to release new major versions of components.  There's always downstream effects and more work.

So far what I've learned out of this, is that it would be nice if contract tests would still work when trying to release outside the original plan - so that for example when I released 3.1.3, contract tests knew to run with Reference Data v5.0.1.  I've put in a stub ticket for this here:  https://openlmis.atlassian.net/browse/OLMIS-2542 .  This feels non-trivial to me, but perhaps someone has a spark of inspiration to make this easy?

Best,
Josh

[Brandon Bowersox-Johnson]

+1 for adding dependency info into the README of each component. That’s a simple thing we can update each time we release, just like we update the CHANGELOG. Then those README files will be a historical record of which component versions worked with which others. I think that’s a simple task with a big benefit for this situation.

 

-Brandon

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/6238674b-b909-43c9-9b3e-1ef6520aa575%40googlegroups.com.

[Paweł Gesek]

I think the problem is that Malawi tried to update one service independently based on the service version it was working towards - and this wasn't possible, due to a patch version forcing a major update to reference data - the version ignores this coupling.

If we list out the dependency versions and the dependency versions of the new version  the component is working towards, this will help, but it still makes things complicated for implementers trying to figure out if they can apply a patch to a given service.

Regards,
Paweł

To view this discussion on the web visit https://groups.google.com/d/msgid/openlmis-dev/EDD525B8-9E0D-4E2C-845F-11A113E0630E%40villagereach.org.

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