Update dev to 3.14.2#453
Conversation
* includes DASH Pod Keep Alive Feature; * update Scrips define_common.sh
| url = https://github.com/LoopKit/LibreTransmitter.git | ||
| [submodule "OmnipodKit"] | ||
| path = OmnipodKit | ||
| url = https://github.com/loopandlearn/OmnipodKit |
There was a problem hiding this comment.
I would prefer all the core device integrations for DIY Loop to remain in LoopKit. If there's some strong reason not to host it locally, let me know.
There was a problem hiding this comment.
Also, I don't think we should be punting the decision of which driver set to use (omnikit/omnible vs omnipodkit) to the user. That adds complexity for the user, for documentation, etc. When the new package is ready, it should be the integration for omnipod, and the old ones removed. I saw there is some automigration on the Loop side, which is nice.
There was a problem hiding this comment.
Just realized maybe my second point was already the plan. I think that's good; just would prefer that kind of unfinished business to stay on dev, and not be in a release.
There was a problem hiding this comment.
Regarding hosting of new managers - we have OmnipodKit pump manager plus others that we want to support in Loop. They are coming from other repositories:
e.g.
bastiaanv:DanaKit:dev \
bastiaanv:EversenseKit:dev \
jbr7rr:MedtrumKit:dev \
loopandlearn:OmnipodKit:main \
with at least one more to come that is private at this time.
We could set up forks within LoopKit for those repositories, and could set up scripts to keep them up to date with the upstream repositories.
There was a problem hiding this comment.
Regarding the proposed configuration for dev and main 3.14.2, this is a temporary situation that is leading to having only OmnipodKit in feature branches, in the incoming tidepool-sync and in future releases.
This is why we need a main and dev version with all three pump managers before we make available a branch with only OmnipodKit.
- If someone builds a feature branch that has only OmnipodKit, their current pod is converted to the OmnipodKit manager automatically
- If that same person then builds a version of main or dev that does not have OmnipodKit, they lose control of their pod
- We have tested this scenario and if the user follows up by building the feature branch again, communication is restored
- However, we want to protect against someone trying a feature branch and then deciding that branch is not ready yet
- By having all 3 managers in main and dev, we can transition safely
- Users can decide to test out the new OmnipodKit by changing between pods while still in main or dev
- Users can back up from a feature branch to main and dev and still have OmnipodKit available
We expect to move quickly to the next version where only OmnipodKit is provided, but we want to enable a wider pool of testers before forcing people to move to the new manager.
There was a problem hiding this comment.
Sounds like a good setup for dev, and not actually have a release, if we're not confident for release.
2 participants
Purpose: Prepare for updating dev to version 3.14.2
With this PR, we are preparing for the next update to dev.
Collect updates to
devbranch prior to merge intodev.devas version 3.14.2The
Detailssection of this PR will be updated with each commit added to this PR.Details
OmnipodKit
What
Adds OmnipodKit as a new submodule.
Why
Pod-type fragmentation across two separate pump managers means duplicated DIY maintenance work (two trees of fixes, two compatibility matrices, two telemetry profiles). OmnipodKit consolidates the protocols into a single codebase. Adopting it as an opt-in alongside the existing managers lets us validate it in the field without disrupting users on the established drivers.
What is not changing
OmniKit (Eros) and OmniBLE (DASH) remain in place for now — existing users on those managers keep working unchanged.
Future versions will handle that conversion automatically when the OmniBLE and OmniKit submodules are removed from the build.
At this time: