-
Notifications
You must be signed in to change notification settings - Fork 71.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
prepare release 14.2.6, development area post 14.2.5 release #7237
Conversation
merge request
This helps create an area for developing towards the next version.
Allow users to choose whether or not to reveal the provenance of the data to consumers. This is intended to help protect data rights to portability and access. If consumers start abusing or discriminating against Nightscout users due to the source of the data, this allows users to conceal this information.
Disregard brand of device when considering glucose values. By de facto usage, the meaning of LOW and HIGH within Nightscout means that glucose is beyond limits. LOW means 40 or lower. HIGH means 400 or higher. Both tend to invite questioning therapy options, including inspecting if the device is working correctly, as well as potential treatment options.
The results to render may come from an in-memory cache, or from the database. If they came from the in-memory cache, it's possible that obscurring the device field could actually change the values in memory. When obscurring, the device field, this patch copies all of the values in order to ensure that the in-memory copies are unaffected. With this patch, cached objects should not be affected.
With this change, any code referencing the sandbox or /api/v2/properties for plugin will also benefit from having the device information obscured.
…/cgm-remote-monitor into wip/bewest/obscure-provenance
obscure private device provenance
…rdless of units (#7273)
Temporarily use git references to share2nightscout-bridge and minimed-connect-to-nightscout in order to help test similar changes in those packages.
The tests pass cleanly.
Change deduping interval
Run tests also against nodejs 16.x
Omnipod reservoir fixes
…emote-monitor into wip/bewest/upgrade-node
This reverts commit ead83e0. Minor differences are causing the tests to fail consistently.
Wip/bewest/upgrade node
There are several features in dev branch needed for expected operation.
Should we consider bumping the version to something other than 14.2.6? |
Here's an attempt at implementing |
npm ls fsevent didn't list any output. I'm running on linux, and regenerating this file after removing it seems to remove the fsevent package from the file. It's likely that fsevent may be used in development mode as part of one of the build utilities, but it shouldn't block anyone from deploying. #7475
The build still fails for node 12.x. Skip optional dependencies. https://stackoverflow.com/a/48953213
@bewest Yes, Loop 3.0 will require these features. |
Actually, testing the dev branch again, I notice a significant bug, and filed a PR to fix it here: #7488 |
Fix incorrect appending for loop enacted status. LGTM.
Remove npm list from engine as it is intended to be advisory.
…ote-monitor into wip/bewest/issue-7475
This makes the testing framework and the advertised node versions match, one for one.
rm package-lock.json && npm install
Allow Remote Carb Entries in Past or Future
@sulkaharo Let's release this as |
* Build docker image for arm64 architecture * Add `platforms` input * Merge `master` and `dev` jobs together into one * Run job on master or dev branch
There are several features in dev branch needed for expected operation.