Branch Management for OSH

Projects
1

Hey there! Two years ago we had some lengthy discussions at OSI² regarding our branch management. The situation is as follows:

Medical hardware tends to circulate for a long time as building it takes significant effort. People that replicated the OSI² ONE v1.0.0 MRI scanner will probably want to fix bugs that they might encounter on the way, instead of replacing the entire setup with a newer version.

So we came up with a scheme that aims to facilitate retrospective bug-fixing and feature development for old versions (especially MDR-certified versions), while not hindering the parallel development of new ones, documented here

I was wondering:

  1. what other solutions other projects have found for their scenario and
  2. since it’s becoming a recurring question: if someone would be up for writing a paper together, e.g. for the Journal of Open Hardware

I was lurking a little towards @julianstirling; the branch management of OpenFlexure reminds me of OpenFlexure. How do you deal with issues of older versions of the microscope? Do you deal with them at all? I assume the “cost of change” might be low enough to justify hardware upgrades instead of fixes for older models, but that’s just my gut feeling

2 Likes
2

Normally the way software works is once you release V1.0.0, new features go into V1.1.0, and bugfixes to V1.0.0 go into V1.01. In practice, in Git this is normally done by the main branch of the repository following the “release” and then you make bugfix branches for anything in support that is getting bugfixes.

OpenFlexure did a bit of this for v6 as we moved onto v7. We have taken the rather strange move of deciding to keep v7 in pre release but also deprecating v6. This was because v7-beta was so so so much more stable than v6, but we wanted to stop iterating through the version numbers so quickly. The full v7.0.0 will be out in a few months, after this we will need to do bugfixes as well as development again. git cherry-pick is useful before branches diverge too much.

The main issue with supporting older version is resources, this is something where medical device regulations come with requirements to resource this sort of thing properly.

2 Likes
3

@julianstirling thanks for this! I had no idea there was a system to this! I thought it was random craziness!

4

here’s the reference : ) https://semver.org/

1 Like
5

sounds reasonable :ok_hand:
our approach with long-term support at OSI² is basically to keep the older branches “alive”. The core team won’t have the resources to look after many many versions of all the modules of the scanner (but of course, clinically certified versions will receive this attention). However, people fixing bugs of older versions can push them to the dedicated branch, sharing it for all, instead of being forced to keep solutions on their own forks

1 Like