chore(release): Add release notes for v7.2.0 database migrations #14409
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## edge #14409 +/- ##
=======================================
Coverage 68.25% 68.25%
=======================================
Files 1629 1629
Lines 54889 54889
Branches 4125 4125
=======================================
Hits 37465 37465
Misses 16735 16735
Partials 689 689
Flags with carried forward coverage won't be shown. Click here to find out more. |
|
|
||
| This update may take longer than usual if your robot has a lot of long protocols and runs stored on it. Allow **approximately 25 minutes** for your robot to restart. This delay will only happen once. | ||
|
|
||
| If you don't care about preserving your labware offsets and run history, you can avoid the delay. Clear your runs and protocols before starting this update. Go to **Robot Settings** > **Device Reset** and select **Clear protocol run history**. |
There was a problem hiding this comment.
I wonder if the first sentence could be removed altogether. Go straight into the tip about making the update faster. Let the reader decide if they want to remove runs and protocols or not.
"For faster update times, clear all your runs and protocols from the robot before starting this process. Go to Robot Settings > Device Reset and select Clear protocol run history."
OR
"For faster update times, you can clear ..."
"For faster update times, consider clearing ..."
Maybe then end with a sentence that conveys the idea that clearing this stored/saved info is optional.
Changelog
Explain that the
/runs/commandsendpoints should be faster now. This covers #14348.Explain that there will be a slow migration upon first boot. This covers #14348 and #14355. See RSS-451 for the math behind my estimate of 25 minutes.
Review requests
Do we want to be more nuanced about the expected update time? It's likely to be much faster if you only ever run short protocols. See RSS-451.
Is suggesting a device reset to avoid the migration delay a good idea? Note that the device reset incurs its own reboot, so it will eat up a few minutes on its own.