VersionWarning#1086
Conversation
| set({ skipUpdate: false }); | ||
| } else { | ||
| set({ status: s, loaded: true, disconnected: false }); | ||
| if(s.info.version != "0.4.11"){ |
There was a problem hiding this comment.
I would like a more robust version pin than "Remember to update this line before every update"
Finding a way for react to store the poetry version would be ideal, but any way that doesn't require intentional manual upkeep is mandatory for this imo
There was a problem hiding this comment.
#1086 (comment)
Updated this line to:
if(s.info.version != import.meta.env.VITE_BACKEND_VERSION){
|
This PR also has a lot of changes to the various StatusBar style components, that's due to me waffling about which version I should use and wanting them all to have feature parity as I found upgrades I could easily build for my immediate needs |
| echo "Building web app" | ||
| pushd ../web # Change to web directory | ||
| npm install # Install nodejs dependencies | ||
| echo "VITE_BACKEND_VERSION=$(poetry version -s)" > .env # Collect the version number and bake it into the frontend |
There was a problem hiding this comment.
I've learned that Vite can bake environment variables into the compiled webapp if you use a dotenv and prefix the vars with VITE_ so I dynamically grab the poetry version and put it in a .env at build time
SteveMicroNova
force-pushed
the
VersionWarning
branch
2 times, most recently
from
cbb7b8f to
0233d21
Compare
SteveMicroNova
force-pushed
the
VersionWarning
branch
from
862f88e to
e129535
Compare
Should these be at least in a separate commit? Maybe even a separate PR? |
|
Is there a reason the bar on desktop is left aligned? |
At least one batch of changes is useful and belongs in this PR, and given that those components are all slightly different takes on the same base thing* I feel like retaining feature parity without splitting that into multiple PRs could have value (*) They're all notification things, they just have different levels of working out of the box vs granular control schemes |
|
A standard way to do this is to stack the "upgrade" first and then to add the "feature" |
|
New versions: 
|
2 participants
What does this change intend to accomplish?
If you have a cached version of amplipi, or keep the site open in another tab / in the app before and after an update, your code is liable to be mismatched with the backend and have odd behaviors. This warning surfaces that issue to the user so they know that they're in need of restarting their browser/app or clearing their cache.
Desktop:
Mobile:
Checklist
./scripts/test