**This blog post is for Loop users**
Lots of people are asking for help understanding whether they “need” to update right now and if so which branch. This answer is best provided with some links and longer explanation, so I’m choosing to do this outside the FB or instagram platform.
What is GitHub?
First step to understanding all of this topic is to know a bit about GitHub. GitHub (in layman’s version) is where developers of programs store their code for open sharing. Kind of like a public lending library of projects.A project in GitHub is called a “repo” or repository in geek-speak. Loop is a project/repo in that lending library of GitHub.
Loop, the app, is actually a product of several repo’s stored in GitHub. While you only download the one Loop repo, there are several other repos that are brought in as part of the build process. The have names like LoopKit, CGMBLEkit, rileylink_ios, dexcom-share-client-swift, G4ShareSpy, and a few others. I mention this now because those other repos will be discussed later in the post.
What is a branch?
Extending this idea of a lending library…GitHub is a place where programmers are sharing their code. Let’s pretend the programmers are cooks, their codes are actually recipes for how to make favorite dinners, and their repo is a cookbook of various recipes. At some point of time, the cook decides…after a lot of experimenting in the kitchen…that a recipe is great. Perfect. And then after much back and forth, the cookbook is done. Ready for publishing with all those great recipes. That book is published and put on the shelves in the bookstore.
That cookbook is called the “master” branch and the process of putting it on the bookshelf is called a release. The author is saying “HEY EVERYONE…this cookbook is super great shape. Recipes have been tested by a lot of people, editors have proofread for typos, pictures are great…go ahead and use for your next party.”
So…master branch is stable. Known quantity. Well-tested. Identified with a “release” version…similar to when books are published.
But, then the cook gets inspired by some new spices. She goes on a trip to a new country and says “Hey, maybe I could actually improve on that old chicken parm recipe? And I’d love to add that pesto dish I tried in Italy.” So, the cook starts marking up the old master cookbook with a pencil. She makes edits to the master cookbook. The edits aren’t perfect on the first try. They take some tweaking. Some recipe edits might need a couple tries before they work quite well enough.
This marked-up, in-progress version of the cookbook is called the dev branch. It may have bugs and things that aren’t quite working well yet. People using recipes from this cookbook may encounter not-quite-right-yet results. But, if the *right* kind of people are using dev branch and providing the chef quality, detailed feedback, then the chef can get those recipes dialed in a little quicker.
Once the dev branch’s recipe edits and additions are well-tested and stable again, the chef will publish an updated version of the cookbook. When this happens, the master branch get updated and a new “release” is announced.
And then the process starts all over again when the chef has a new recipe in development…iterative process for code development involves this master and dev interaction. Dev is the playground for new features to be worked on…master is where they all merge together after testing is done in dev. Master will be updated infrequently, but dev will have more frequent changes that are almost always unannounced (see the discussion below about commit history to know how to “track” dev changes)
Which branch of Loop to get?
When you download Loop code, you will be downloading a specific branch of Loop code. Often the question is “Which branch should I get then?”
The branch you use will depend on WHEN you are building, and to a certain degree your willingness to use versions that might be glitchy. In other words…the answer to “which branch to use?” will change over time based on where Loop development is. You will need to read Loopdocs to know the current landscape of branches in order to best inform your choice.
For example as of TODAY August 24th (and as described in Loopdocs)
- Master branch only supports Medtronic looping.
- Dev branch supports Omnipod and Medtronic looping and has overrides feature merged in and has a fix for the IOB tracking of short temp basal rates for pod users.
- Omnipod-testing branch supports Omnipod and Medtronic looping but does not have overrides feature merged in nor the IOB tracking fix.
Why not use dev?
So, most Omnipod loop users right now will be thinking “Well heck, why not update to dev branch right now then?” There’s a few reasons.
Dev branch users should be EXPECTING AND WILLING AND ABLE to update frequently. Do you have access to a computer? Are you willing to update frequently as fixes are pushed? Dev branch will have frequent updates to fix bugs that are revealed during testing of the new code edits…and you will want to grab them.
Finally…let’s be honest about you the user. If you see an error in your Loop app after you decide to install dev branch…will you be the type to HELP with the solution or merely whine about the problem? Dev branch updates are really helped by people who know how to capture Issue Reports and explain what they are seeing. What really slows programmers down is having a bunch of people complaining about bugs but without any accompanying documentation to help log the cause of the bug. Looped group support does not need a bunch of people saying “I’m on dev and it’s not working”. This will not help.
If you are using dev branch, you should also be capable of using Descriptive Language to help report bugs or problems.
If you can’t use descriptive language, you probably shouldn’t use dev branch right now. This is important. Thanks!
In the near future, dev updates will slow down again. Kind of like when you decide to undertake a big decorating project in your house…lots and lots of changes at first and then the pace slows down a bit. Fewer changes and things narrowing down to a final version. How long in the near future? I don’t know. But, in the not distant future (weeks?), omnipod-testing branch will be gone and we will officially start to tell people to use dev branch for omnipod looping because the updates will have slowed and the dev branch’s edits will be stable enough that the average user shouldn’t have too difficult a time with the user experience.
But can you use dev branch now?
Sure. BUT…you have been warned. There may be some bugs and if you want to report them or ask about them…you will need to use DESCRIPTIVE LANGUAGE and capture Issue Reports to help explain what you are seeing/experiencing. And you should expect to want to update to get those bug fixes.
How often are these dev updates happening lately? Dev branch has been updated 13 of the 24 days in August so far.
What are the bugs?
So you want me to list out the bugs so that you can decide if the bugs are “bad enough” that you don’t want to risk it? Or “not so bad” that you want to try dev?
That’s not how this works. When code is changed, there’s no exhaustive list of all the bugs that comes with the code change. The bugs are identified through use and testing. I may be able to tell you that I *think* most of the bugs are display-related right now…but that is absolutely no guarantee that there couldn’t be a bigger bug yet to be identified (similar to the IOB tracking bug that is in omnipod-testing branch right now). Some bugs just take a lot of testing to finally surface and identify.
But what about my JoJo features if I move to dev?
If you want to move to dev, that’s fine. But, you will lose JoJo specific features, that is true. I will not be updating Jojo yet myself to the new dev branch until dev revisions slow down a bit.
Can you edit dev to include your favorite Jojo features now? Sure, but depending on the particular feature…it may be difficult and tedious to keep up the effort right now. For example, the edit for bolusing down to 55 mg/dL is a super easy edit, but the edit for Remote Temp Targets in Nightscout is difficult.
More globally, I’m working with Loop developer Pete to try to get Jojo features (at least most of them) rolled into main Loop branches anyways. So, hopefully main Loop branches would have all the JoJo stuff soon anyways…and if any are left out, those could be left for users to do as easy code customizations.
How do you get Loop code?
The LoopDocs site has you download Loop’s code as a package to your computer. That package is kind of like a xerox copy of the Loop code at a point in time. That part is important…A POINT IN TIME. The code that sits on your computer, when you download it, does not track updates that might be added to Loop’s code later. If you want updated code, you have to go out and ask GitHub for a new xerox copy…aka download code again.
How do you know what age your Loop code is?
Every change to the code in Loop is tracked as “commits”. These commits are logged individually…every single one of them. That is the great part about GitHub for developers. They can see exactly what lines were changed, by whom, when those were changed, and they usually include a very brief explanation of what the change was for. The analogy for those who aren’t programmers…it’s like seeing your Word document in track-changes mode.
So, the date you download your code is timestamped on your download folder. Select your Loop download folder and press command-i to bring up the folder’s info (or right-click and choose “get info”). The “created on” date is the date that your code that you’ll use for Loop is current to…in other words, the last commit that was made in your downloaded Loop code is that created date.
In the screenshot above, that indicates that the Loop code (dev branch because I can see that in the folder name) is current through any changes up until July 26th.
How can I compare my download vs current branch’s status?
If you want to see what’s happened to any branch since the date you downloaded your Loop code…that’s easy. GitHub has a log of all the commit history sorted by date. A “commit” is an edit to the code.
Loop master branch commit history
Loop dev branch commit history
Loop omnipod-testing branch commit history
Simply look and see if any commits have come in since you downloaded…if there’s been new commits, then you can decide to update your Loop app with a fresh download. Do you *have* to update? Not usually…but sometimes there’s good reason to prioritize an update sooner rather than later. For example, if you get one of those new G6 transmitters…you’d definitely want to have your Loop app updated as those commits came in on July 18th…you can practice looking at the commit log and find the G6 updates in the commit history. Check your download and see if you downloaded before or after that commit was made. If you downloaded your code before July 18th, then you will want to update before you get an updated G6 transmitter style.
So, if you decide to update to dev branch and wonder whether it’s been updated since you built it last…that’s how to check.