- Paul Baker firstname.lastname@example.org (PB)
- Pedro Barreto email@example.com (PSB)
- Miguel de Barros firstname.lastname@example.org (MdB)
- Lewis Daly email@example.com (LD)
- Johann Foley firstname.lastname@example.org (JF)
- Sam Kummary email@example.com (SK)
- Godfrey Kutumela firstname.lastname@example.org (GK)
- Istvan Molnar email@example.com (IM)
- Simeon Oriko firstname.lastname@example.org (SO)
- Justus Ortlepp email@example.com (JO)
- Michael Richards Michael.Richards@modusbox.com (MR) (chair)
Apologies: SK, SO, BS, IM, JO
- Review actions from previous meeting
- Issue 78: Upgrading node version to the latest LTS
- Comments from TGB presentation
Comments received from TGB meeting:
Can we have an automated analysis of where there are problems (e.g. lint)?
Are we using any edge technologies that we know of?
Modify the contribution strategy to ensure that tests are run on the latest version of node.js - acceptance depends on using latest version
Release should always be using the latest node…
Can we co-ordinate this with the Microsoft Azure team - are they doing this anyway?
We have to do some tooling work.
MS can do some verification work
How do we ensure that our release process works?
Do we have tooling that can spot this?
How can we ensure that old versions of Node aren’t being pulled in?
Figure the rules out, then ask what tools can support this?
Actions reviewed. Mostly closed, jolly good show
MdB: lint wouldn’t pick up a lot of the things that we need to know about. There aren’t any syntax changes. PSB: use deprecation list of the release notes. MD: Go one repository at a time, do the upgrade, run the tests, see if anything needs to be done. What to do where there are no, or insufficient, tests? Unit tests generally present, integration tests not so much. Eventually everything will have to pass a full Golden Path suite.
Edge technologies: we don’t think they are very much used, certainly not as a general proposition…
How are we going to ensure that tests use the latest release of node.js? MdB: Only feasible for new code, not modifications. We would lose contributors, you’d need to know too much about Mojaloop and we’re trying to reduce the required knowledge. JF: We could offer exceptions PSB, MdB: don’t like that - will still kill contributions.
Release should always be using the latest version. PSB: sounds good. MdB: things are maintained by different groups. Code is pre-packaged into Docker containers, it’s not the responsibility of the developer to know what release their dependencies are at… PSB: we always release with active LTS. You can experiment with later versions… MdB: Helm release every quarter, code releases much more frequent. We must have a public release schedule, but this needs a maintenance team, or is there any alternative?
Use the MS team. Will everything be contributed back? E.g. Helm charts. Are they looking at individual components? They only care about containers. They might be modifying Helm charts, but they’re not changing code. So they’re changing Kafka and MySql…
Scripting can go through the repositories, flag the versions… PSB
- MR: Describe Alternative support models.
- MR: Talk to Azure team, see if they can help
- PSB: develop script to check repositories