branch | version # |
last updated | comments |
|:--|:--|:--|:--|
| main | 3.14.0 | 14 May 2026 | release |
-| dev | 3.14.1 | 23 May 2026 | functionally the same as `main`
3.14.1: [PR 452](https://github.com/LoopKit/LoopWorkspace/pull/452#top) add alert about dev branch |
-| [feat/dev-dana-medtrum](#feature-branch-dana-and-medtrum-support)
- SHA `e0331eb` | 3.14.1 | 26 May 2026 | - adds support for Dana and Medtrum pumps
- SHA `DanaKit @ c544c42`
- SHA `MedtrumKit @ 6060747`
**Medtrum User Interface Redesigned** to be more like the Omnipod User Interac.
Several fixes added for MedtrumKit, not yet in DanaKit |
-| [feat/eversense](#feature-branch-eversense-support)
- SHA `e909b2e` | 3.14.1 | 26 May 2026 | - adds experimental support for Eversense (includes Dana and Medtrum pumps support - same SHA as above)
- this branch is ready for use to evaluate and report back
- SHA `EversenseKit @ 43b8080` |
-| [feat/omnipodkit](#feature-branch-omnipodkit-pump-manager)
- SHA `a625519` | 3.14.1 | 01 June 2026| The new OmnipodKit pump manager, controls all Types of pods. Initially only the Eros and DASH pod types are available for feature branch testers
- SHA `OmnipodKit @ c04c4d4`
**Please read [Feature Branch: OmnipodKit Pump Manager](#feature-branch-omnipodkit-pump-manager)** |
-
-!!! important "Eversense Support"
- The Eversense CGM is now supported by the *Loop* app in a feature branch. To simplify maintenance, the branch which supports Eversense also supports the two new pumps: Dana and Medtrum.
-
- The branch which support Evensense E3 and E365 CGM is simply called `feat/eversense`.
+| dev | 3.14.2 | 5 June 2026 | v3.14.2 has a breaking change wrt `main`
- v3.14.1: [PR 452](https://github.com/LoopKit/LoopWorkspace/pull/452#top) add alert about dev branch
- v3.14.2 [PR 453](https://github.com/LoopKit/LoopWorkspace/pull/453)
- add MedtrumKit
- add EversenseKit
- add OmnipodKit
- delete OmniBLE and OmniKit
**Please read** [Transition to OmnipodKit](#transition-to-omnipodkit) |
+| `feat/all-managers`
- SHA `1b4718f` | 3.14.2 | 5 June 2026| This branch contains all the managers and is primarily for developers to use for testing
It also provides `DanaKit @ c544c42` support
**Please read** [Status for Dana Support](#status-for-dana-support)
**Please read** [Feature Branch: feat/all-managers](#feature-branch-featall-managers) |
+| `next-dev` | 3.15.0 | subject to rapid change | [PR 454](https://github.com/LoopKit/LoopWorkspace/pull/454)
[zulipchat: Loop next-dev Status](https://loop.zulipchat.com/#narrow/channel/144182-development/topic/Loop.20next-dev.20Status/with/600761707) |
??? question "What is SHA? (Click to Open/Close)"
SHA-1 means Secure Hash Algorithm 1. This is used to generate an alphanumeric code to identify which version of a repository is used.
@@ -71,6 +105,14 @@ The table below lists active branches. Note that updates may occur and be announ
The SHA-1 20-character value is abbreviated as SHA and typically only the first 7 or 8 characters are presented to identify the commit for a particular repository.
+### Table of Retired Branches
+
+| Retired Branch | Use Instead | Status Link |
+|:--|:--|:--|
+| feat/dev-dana-medtrum |For Medtrum, use `dev`
For Dana, use `feat/all-managers` | [Status for Medtrum](#status-for-medtrum-support)
[Status for Dana](#status-for-dana-support) |
+| feat/eversense | For Eversense, use `dev` | [Status for Eversense](#status-for-eversense-support) |
+| feat/omnipodkit | Use `dev` unless you are a developer
developers can use `feat/all-managers` | [Feature Branch: feat/all-managers](#feature-branch-featall-managers) |
+
### How to Build Feature Branches
For full instructions on building different branches, review these pages:
@@ -87,93 +129,59 @@ Use the page linked above to add the desired branch name (from the table above)
For Mac Xcode build, the lines you need to copy and paste into a Terminal window are explicitly provided below:
-``` { .bash .copy title="Download and build the feat/omnipodkit branch" }
-/bin/bash -c "$(curl -fsSL \
- https://raw.githubusercontent.com/loopandlearn/lnl-scripts/main/BuildLoop.sh)" \
- - feat/omnipodkit
-```
-
-``` { .bash .copy title="Download and build the feat/dev-dana-medtrum branch" }
+``` { .bash .copy title="Download and build the feat/all-managers branch" }
/bin/bash -c "$(curl -fsSL \
https://raw.githubusercontent.com/loopandlearn/lnl-scripts/main/BuildLoop.sh)" \
- - feat/dev-dana-medtrum
+ - feat/all-managers
```
-``` { .bash .copy title="Download and build the feat/eversense branch" }
-/bin/bash -c "$(curl -fsSL \
- https://raw.githubusercontent.com/loopandlearn/lnl-scripts/main/BuildLoop.sh)" \
- - feat/eversense
-```
### Version Number Plan
Please see [`Loop` Version Numbering](releases.md#loop-version-numbering) for the current method for version numbering for the `main` and `dev` branches.
-The idea of having a feature branch is not new for the *Loop* app but hasn't been used for a few years. At this point, we have several feature branches.
-
The version number in the feature branch will match either the `dev` branch version number or a work-in-progress update to the `dev` branch which uses the naming convention `update_dev_to_M.m.#`.
* In other words, the feature branch is up to date with other changes to `dev` or `update_dev_to_M.m.#` with the added support for the specific feature
* Each feature has an associated repository that contains the feature
* When updates to the feature are added, the SHA for the feature branch and the SHA for the submodule(s) which support that feature will be reported in the table above and can be found by examining the LoopWorkspace repository for that feature branch
-### Feature Branch: OmnipodKit Pump Manager
-
-You need to build the `feat/omnipodkit` branch if you want to test the new `All Omnipod Types` pump manager. Build instructions are found here: [How to Build Feature Branches](#how-to-build-feature-branches).
-
-This pump manager comes with improved user interface and user experience for Omnipod Classic (Eros) and DASH pods including
-
-* Some layout adjustments
-* Some new labels
-* Some reworked sub-menus with added information or features
-
-The next time you change a pod, delete the pump manager you are using and add a new pump. See [Change Pump Type](loop-3/add-pump.md#change-pump-type){: target="_blank" } for detailed instructions.
-
-* Select `All Omnipod Types` as your new pump manager.
-* Go through the onboarding of selecting notifications and reminders and insulin type.
-* You will then be presented with a screen to select the type of pod.
-* Choose the Classic (Eros) or DASH Pod type
-
-The underyling control code should be the same, but we want more people testing it to ensure this works as well as the older pod managers. The developers have been using it on themselves before making this publicly available.
-
-!!! question "Why OmnipodKit?"
- When the initial work to add DASH to the supported pumps was started in 2021, a completely separate pump submodule was created distinct from the Classic (Eros) pump submodule. In other words, OmniBLE handled DASH and OmniKit handled Eros.
-
- A significant portion of the two repositories serve the same function. Whenever a fix or improvement was added to OmniBLE, it was duplicated and added to OmniKit. Having a universal pod manager saves significant developer resources.
+- - -
- OmnipodKit provides the individual support needed for different `Pod Types` while using a single copy of code for most of the logic and user interface.
+### Status for Pod Keep Alive Support
- The improvements that have been going on in the background landed in the new pump manager only - and were not replicated in the OmniKit or OmniBLE repositories.
+For those using iPhone 16 or 17e with Atlas DASH Pods, the keep alive support is available in the released code, `main`, v3.14.0 or in the development code, `dev`, v3.14.2.
- This will be a significant time saver for developers moving forward for updating code and adding support for new types of pods.
+- - -
-!!! tip "feat/omnipodkit supports other plugins"
- For the convenience of the developers and testers, this feature branch, feat/omnipodkit, also supports the new pump and cgm managers that are found in the other feature branches.
+### Status for Medtrum Support
- In other words:
+Medtrum support was added to the `dev` branch in version 3.14.2.
- * Eversense is available as a CGM
- * Dana and Medtrum are available as a pump, in addtion to OmnipodKit and all the older pump managers
+- - -
-### Feature Branch: Pod Keep Alive Feature
+### Status for Eversense Support
-The feat/pod-keep-alive branch has been deleted. It was updated and incorporated into the released code. Please build the `main` branch over your existing app. All your selections will remain as you configured them when building the `feat/pod-keep-alive` branch.
+Eversense support was added to the `dev` branch in version 3.14.2.
-See [Pod Keep Alive Feature](../loop-3/omnipod.md#pod-keep-alive-feature){: target="_blank" }.
+- - -
+### Status for Dana Support
-### Feature Branch: Dana and Medtrum Support
+For Dana support, you must build a new feature branch, feat/all-managers. The old feature branches will be deleted without further warning.
-Anyone using Dana or Medtrum pumps must build one of these branches. The pump manager support is identical. The difference is the second one includes support for the Eversense CGM. Build instructions are found here: [How to Build Feature Branches](#how-to-build-feature-branches).
+* Build instructions are found here: [How to Build Feature Branches](#how-to-build-feature-branches).
+* See [Feature Branch: feat/all-managers](#feature-branch-featall-managers) for more information about the branch.
+* Keep reading here for Dana specific status.
-* `feat/dev-dana-medtrum`
-* `feat/eversense`
-!!! important "New Pump Managers"
- These are new Pump Managers and may have known or unknown bugs. Please only use a feature branch if you are prepared to follow along in zulipchat and are willing to help test and resolve issues. This is critical when using new pump managers.
+!!! important "New Managers"
+ The `feat/all-managers` branch is used to add new Pump Managers and CGM Managers which may have known or unknown bugs. Once the managers are deemed reliable, they are added to the `dev` branch and subsequently released. This branch contains new and old managers (like OmniBLE and OmniKit) for use by developers.
+
+ Please only use a feature branch if you are prepared to follow along in zulipchat and are willing to help test and resolve issues. This is critical when using new pump managers.
* Please ensure you have the latest version of a given branch by synching before you build:
- * Browser Build: be sure you select `feat/dev-dana-medtrum` or `feat/eversense` branch
+ * Browser Build: be sure you select `feat/all-managers` branch
* The Build Loop action automatically syncs your fork when building
* Be sure to install the resultant build from *TestFlight* onto your phone
* Mac-Xcode: you can update your clone or download a fresh copy
@@ -185,23 +193,11 @@ Anyone using Dana or Medtrum pumps must build one of these branches. The pump ma
The behavior of your OS-AID system needs to properly handle bolus and temp basal rate events in progress if that communication is interrupted. This can happen if someone walks away from their phone during a bolus or while a temp basal rate is in progress.
- Please read the rest of this section to learn about how this might affect an older or current version of your OS-AID app.
-
-#### Recently Closed Issue for Medtrum
+ These issues were fixed in MedtrumKit and the lessons learned will be applied to DanaKit.
-!!! success "Medtrum Bluetooth Comms Loss Updated"
+ There are known issues for DanaKit, which is why that pump manager is not yet in the `dev` branch
- #### MedtrumKit - fixed on 29 April 2026
-
- [MedtrumKit Issue 112](https://github.com/jbr7rr/MedtrumKit/issues/112) reported that MedtrumKit did not properly handle a Temp Basal Rate (TBR) event if BLE comms was lost at the time the TBR completed.
-
- [MedtrumKit PR 118](https://github.com/jbr7rr/MedtrumKit/pull/118) provided an updated management of TBR providing accurate handling of TBR when BLE was interrupted and later restored.
-
- #### MedtrumKit - fixed on 25 March 2026
-
- [MedtrumKit Issue 92](https://github.com/jbr7rr/MedtrumKit/issues/92) reported that when the Medtrum moved out of Bluetooth range, the app reported an interrupted bolus when in fact the bolus continued. This led to underreported values for Active Insulin, also known as Insulin on Board (IOB).
-
- [MedtrumKit Pull Request 93](https://github.com/jbr7rr/MedtrumKit/pull/93) fixed this issue. Now if Bluetooth communication is lost, the pump manager relies on expected timing to continue the bolus progress display. The bolus is not considered final until BLE is restored and the app is able to communicate with the pump.
+ Please read the rest of this section to learn about how this might affect an older or current version of your OS-AID app.
#### Open Issue for DanaKit
@@ -238,42 +234,61 @@ Anyone using Dana or Medtrum pumps must build one of these branches. The pump ma
- - -
-### Feature Branch: Eversense Support
+### Feature Branch: feat/all-managers
-#### Recently Closed Issue for Eversense
+The `feat/all-managers` branch replaces several [retired feature branches](#table-of-retired-branches). If you need a feature branch for a Dana pump - you need to build this branch. Be sure to review the [Status For Dana Support](#status-for-dana-support) section.
-!!! success "Eversense Placement Guide updated"
+If you previously used a feature branch for Medtrum or Eversense support, you can switch to the `dev` branch.
- #### EversenseKit - fixed on 30 April 2026
+!!! Question "What is different between `feat/all-managers` and `dev` branch"
+ There are several differences between `feat/all-managers` and `dev` branch. For one thing, this branch has all the pump managers: OmniBLE, OmniKit, OmnipodKit, DanaKit, MedtrumKit and MinimedKit and the new CGM manager EversenseKit. When other new managers become available, they may be added here for testing.
- [EversenseKit Issue 26](https://github.com/bastiaanv/EversenseKit/issues/26) reported that the placement guide graph was not updating when attaching the Transmitter over the sensor.
+ Keeping OmniBLE & OmniKit in this branch is useful for developers. Those pump managers were removed from `dev` branch (3.14.2) and will soon be removed from `main` when `dev` is merged into main. We expect those managers will eventually be dropped from this branch, but only when the developers agree to do so.
- [EversenseKit PR 30](https://github.com/bastiaanv/EversenseKit/pull/30) fixed the problem. The solution was to enable debug mode while using the placement guide and disable debug mode when done.
+ Because OmniBLE & OmniKit are present, a tester who comes in with a Pod attached to one of those managers stays with the manager. The automatic conversion to OmnipodKit, which happens with v3.14.2, does not happen with this branch. The tester has to manually change pump managers during a Pod change.
-There is a new feature branch available, `feat/eversense` which supports the Eversense E365 and E3 transmitters. In addition to Eversense support, this branch also has the same pump support as the `feat/dev-dana-medtrum` branch.
+#### Transition to OmnipodKit
-For anyone who tests this branch with Eversense, if there are issues with your use of Loop with Eversense please report in this [zulipchat channel](https://loop.zulipchat.com/#narrow/channel/144182-development/topic/Eversense.20CGM/with/569969251).
+!!! important "Once you transition to OmnipodKit, stay with OmnipodKit"
+ The new unified Omnipod Pump Manager, OmnipodKit, is provided in v3.14.2 or newer.
-Be sure to include:
+ If you are running a Pod and you transition to the OmnipodKit Pump Manager, then any build you install on your phone should have OmnipodKit. If you need to downgrade to a build earlier than v3.14.2, do so after deactivating a Pod.
-* a description of your issue
-* your phone model and iOS version
-* your build method:
- * Browser Build
- * Mac-Xcode and include Xcode version
-* which version of code you are running (branch name and SHA)
-* share your Eversense logs (at bottom of the Loop Eversense screen)
-If you prefer to create an issue directly at the Eversense repo, create it here:
+The OmnipodKit pump manager comes with improved user interface and user experience for Omnipod Classic (Eros) and DASH pods including
-* [https://github.com/bastiaanv/EversenseKit/issues](https://github.com/bastiaanv/EversenseKit/issues)
+* Some layout adjustments
+* Some new labels
+* Some reworked sub-menus with added information or features
-> Note
+If you are running the `dev` branch - your Pod is automatically transitioned to OmnipodKit. You will notice the user interface is a little different. If you are running `feat/all-managers` branch, see [Manual transition with `feat/all-managers`](#manual-transition-with-featall-managers).
-> * This was tested using an E365 transmitter attached to a small vial containing a sensor in glucose solution
-> * This enabled testing the Eversense behavior with Loop on a test phone
-> * No testing with the E3 (3-month, 90-day) sensor has been performed
+One of the biggest things is that you can change Pod types between Pods without deleting the pump manager. That means all your configuration choices for desired notifications and type of Insulin are maintained when you change Pod Types. With this version of OmnipodKit, only Eros and DASH are supported.
+!!! question "Why OmnipodKit?"
+ When the initial work to add DASH to the supported pumps was started in 2021, a completely separate pump submodule was created distinct from the Classic (Eros) pump submodule. In other words, OmniBLE handled DASH and OmniKit handled Eros.
+
+ A significant portion of the two repositories serve the same function. Whenever a fix or improvement was added to OmniBLE, it was duplicated and added to OmniKit. Having a universal pod manager saves significant developer resources.
+
+ OmnipodKit provides the individual support needed for different `Pod Types` while using a single copy of code for most of the logic and user interface.
+
+ The improvements that have been going on in the background landed in the new pump manager only - and were not replicated in the OmniKit or OmniBLE repositories.
+
+ This will be a significant time saver for developers moving forward for updating code and adding support for new types of pods.
+
+#### Manual transition with `feat/all-managers`
+
+If you are running `feat/all-managers` branch, you need to take these steps to switch to using the new pump manager.
+
+The next time you change a pod, delete the pump manager you are using and add a new pump. See [Change Pump Type](../loop-3/add-pump.md#change-pump-type){: target="_blank" } for detailed instructions.
+
+* Select `All Omnipod Types` as your new pump manager.
+* Go through the onboarding of selecting notifications and reminders and insulin type.
+* You will then be presented with a screen to select the type of pod.
+* Choose the Classic (Eros) or DASH Pod type
+
+
+- - -
## Older updates
diff --git a/docs/version/releases.md b/docs/version/releases.md
index 3247abee9ac..1d23bc203cb 100644
--- a/docs/version/releases.md
+++ b/docs/version/releases.md
@@ -217,21 +217,7 @@ This version updates a few iOS 26 interface issues, moves support for Dana pumps
> **A pump manager that works for Trio must be separately tested for Loop**
* Several issues were reported regarding bolus accounting and IOB reporting for *Loop* v3.8.1
-* For this reason, Dana support is only found in 2 special branches
-
-If you were using Dana with v3.8.1, a branch called `release/3.8.1` was created for your continued use.
-
-* The `release/3.8.1` branch will remain available while troubleshooting continues
-* This branch is meant to support people already using Dana with v3.8.1 who understand how to manage the issues with that version
-
-If you are an expert and want to use [Dana](../loop-3/add-pump.md#dana-in-loop-requires-expert-testing){: target="_blank" } or [Medtrum](../loop-3/add-pump.md#medtrum-in-loop-requires-expert-testing){: target="_blank" }, the experimental branch is `feat/dev-dana-medtrum`
-
-* This branch is subject to rapid updates
-* Please do not use Dana with Loop unless you are willing to test and communicate with [developers on zulipchat in this DanaKit channel](https://loop.zulipchat.com/#narrow/channel/144182-development/topic/DanaKit.20Troubleshooting/with/547829260)
-
-* Please do not use Medtrum with Loop unless you are willing to test and communicate with [developers on zulipchat in the Medtrum channel](https://loop.zulipchat.com/#narrow/channel/144182-development/topic/Medtrum.20Nano.20-.20pumps.20for.20development.20use/with/481836247)
-
-
+* For this reason, Dana support is only found in a feature branch
### Loop v3.8.1
@@ -655,9 +641,17 @@ This is one of the bigger updates to Loop. Since the last release [`Loop v2.2.9`
## `Loop` Version Numbering
-With the release of version 3.14.0, the numbering is changing again. We will not be using even numbers for main and odd numbers for dev.
+With the release of version 3.14.0, the numbering is changing again.
+
+### `Loop` 3 versus `Loop` 4
+
+We are bringing in input from Tidepool that brings a whole new set of enhancements. This will eventually be released as version 4.0.0, but while we are testing in a branch called `next-dev`, it will be version 3.15.n.
+
+The existing version of Loop will continue to be updated, but it will all be in the 3.14.n series.
+
+We started out with main and dev at the same number, e.g., 3.14.0. When changes are incorporated into dev via a formal pull request, dev will be bumped up in the last position, e.g., to 3.14.1, then 3.14.2, etc to indicate updates brought into dev. When a given version of dev needs to be released, the main branch will be updated to the same code and version number as the dev branch.
-We will start out with main and dev at the same number, e.g., 3.14.0. When changes are incorporated into dev via a formal pull request, dev will be bumped up in the last position, e.g., to 3.14.1, then 3.14.2, etc to indicate updates brought into dev.
+### Older Version Numbering
With the release of `Loop 3`, there was a new pattern for identifying the releases as distinct from the development work. This pattern was revised again starting with `Loop v3.6`.