github-starred/actual
2
0
Fork 0
mirror of https://github.com/actualbudget/actual.git synced 2026-07-16 07:04:23 -05:00
Code Issues 3.0k Packages Projects Releases 58 Wiki Activity

[PR #3534] [CLOSED] [WIP] :electron: experimenting with dynamically selecting version of client #82592

New Issue
Closed
opened 2026-05-19 07:01:35 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-05-19 07:01:35 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/actualbudget/actual/pull/3534
Author: @MikesGlitch
Created: 9/30/2024
Status: ❌ Closed

Base: master ← Head: electron/dynamic-client-verison-select

📝 Commits (6)

📊 Changes

8 files changed (+99 additions, -10 deletions)

View changed files

📝 packages/desktop-client/src/components/manager/ManagementApp.jsx (+29 -1)
📝 packages/desktop-electron/index.ts (+43 -5)
📝 packages/desktop-electron/package.json (+1 -0)
📝 packages/desktop-electron/preload.ts (+6 -0)
📝 packages/desktop-electron/server.ts (+16 -2)
📝 packages/loot-core/src/server/migrate/migrations.ts (+1 -0)
📝 packages/loot-core/typings/window.d.ts (+1 -0)
📝 yarn.lock (+2 -2)

📄 Description

Third thoughts:

Try to get the server sync working within the desktop app and tunnel into it. Then we may just restrict the usage of the server in Electron to the embedded server? Then they'd never go out of sync.

I was able to run the server locally and expose via nginx to a free domain even when localhost was running in https. Seemed to work fine.

My second thoughts:

This may be the only half-decent way to allow control of versioning inside the electron app. It gives full control to the user about which verison they want to be on. The store's couldn't auto-update us out of that version.

Note - this is just an experiment. I'll likely blow this code away 💣

Why

Some people want the desktop app to be on the same version as their server. The desktop app auto updates when installed from Windows Store/other stores.

The goal

  • Allow the electron app to select the version of the client they wish to be on
  • Bonus points for allowing an "edge" version
  • Decouple the desktop app release from the main app
    • If we can download client code on the fly, we shouldn't need to release unless we change electron code.

Problems

  • What if Client V1 needs the Electron functionality killserver and Client V2 no longer requieres it (so developer deletes the code in electron)
    • The Electron code has now broken contract with Client V1 and the functionality will no longer work 🔥
    • We could mitigate this by only allowing the last 2 versions of the client to be available and marking electron functions as deprecated
    • This is annoying though, as people may not be aware of the requirement to deprecate. This has a high potential for bugs.
  • What if dependency for better_sqlite3 was updated and it broke contract (updated a major release)
    • Client V1 needed better_sqlite3 V1, which had method exec, When it was upgraded the method changed to be called execute and now Client V1 is broken.
      • This could be mitigated by moving the bettersqlite implementation into Electron. Then the version of the package would be locked in to the implementation of the package. Code refactor would be required.

Should we ditch this approach and see if auto-updater allows rolling back versions? That's more fool-proof - it means we don't have to take care about breaking contract between ui and electron code.

UI TODO

  • Make a modal that allows you to select a list of releases. You click download - it downloads one and you can click to use it
  • This would modify the global.json file to specify that you wish to use that release.
  • If pointing at a server, check the server version and if it's different from the client version, notify the user in a toast.

Note: we may want to ship the latest version so that the user doesn't need to download it after installing.

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/actualbudget/actual/pull/3534 **Author:** [@MikesGlitch](https://github.com/MikesGlitch) **Created:** 9/30/2024 **Status:** ❌ Closed **Base:** `master` ← **Head:** `electron/dynamic-client-verison-select` --- ### 📝 Commits (6) - [`5aba7d9`](https://github.com/actualbudget/actual/commit/5aba7d957841db40ababc9298793a94f1e0b2deb) experimenting with electron dynamically selecting version - [`1570bec`](https://github.com/actualbudget/actual/commit/1570becae88df8354658c2bab694d9ac3279c164) fix - [`e506889`](https://github.com/actualbudget/actual/commit/e506889003a9cdafcb36e1fbc4b03409a622194e) cleanup - [`f846f34`](https://github.com/actualbudget/actual/commit/f846f34d6bfddb54d7fc675b8082e7643eea42ac) seems to work - [`6c6c617`](https://github.com/actualbudget/actual/commit/6c6c61719e9aa41327b4d1cc351fa155cc3859ee) updating package - [`7e62d2c`](https://github.com/actualbudget/actual/commit/7e62d2cef16cbc516e1e44727c9427f2f47374ed) changing approach slightlyt ### 📊 Changes **8 files changed** (+99 additions, -10 deletions) <details> <summary>View changed files</summary> 📝 `packages/desktop-client/src/components/manager/ManagementApp.jsx` (+29 -1) 📝 `packages/desktop-electron/index.ts` (+43 -5) 📝 `packages/desktop-electron/package.json` (+1 -0) 📝 `packages/desktop-electron/preload.ts` (+6 -0) 📝 `packages/desktop-electron/server.ts` (+16 -2) 📝 `packages/loot-core/src/server/migrate/migrations.ts` (+1 -0) 📝 `packages/loot-core/typings/window.d.ts` (+1 -0) 📝 `yarn.lock` (+2 -2) </details> ### 📄 Description <!-- Thank you for submitting a pull request! Make sure to follow the instructions to write release notes for your PR — it should only take a minute or two: https://github.com/actualbudget/docs#writing-good-release-notes --> # Third thoughts: Try to get the server sync working within the desktop app and tunnel into it. Then we may just restrict the usage of the server in Electron to the embedded server? Then they'd never go out of sync. I was able to run the server locally and expose via nginx to a free domain even when localhost was running in https. Seemed to work fine. # My second thoughts: This may be the only half-decent way to allow control of versioning inside the electron app. It gives full control to the user about which verison they want to be on. The store's couldn't auto-update us out of that version. ---- Note - this is just an experiment. I'll likely blow this code away 💣 # Why Some people want the desktop app to be on the same version as their server. The desktop app auto updates when installed from Windows Store/other stores. # The goal - Allow the electron app to select the version of the client they wish to be on - Bonus points for allowing an "edge" version - Decouple the desktop app release from the main app - If we can download client code on the fly, we shouldn't need to release unless we change electron code. # Problems - What if Client V1 needs the Electron functionality ```killserver``` and Client V2 no longer requieres it (so developer deletes the code in electron) - The Electron code has now broken contract with Client V1 and the functionality will no longer work :fire: - We could mitigate this by only allowing the last 2 versions of the client to be available and marking electron functions as deprecated - This is annoying though, as people may not be aware of the requirement to deprecate. This has a high potential for bugs. - What if dependency for better_sqlite3 was updated and it broke contract (updated a major release) - Client V1 needed better_sqlite3 V1, which had method ```exec```, When it was upgraded the method changed to be called ```execute``` and now Client V1 is broken. - This could be mitigated by moving the bettersqlite implementation into Electron. Then the version of the package would be locked in to the implementation of the package. Code refactor would be required. Should we ditch this approach and see if auto-updater allows rolling back versions? That's more fool-proof - it means we don't have to take care about breaking contract between ui and electron code. # UI TODO - Make a modal that allows you to select a list of releases. You click download - it downloads one and you can click to use it - This would modify the global.json file to specify that you wish to use that release. - If pointing at a server, check the server version and if it's different from the client version, notify the user in a toast. ## Note: we may want to ship the latest version so that the user doesn't need to download it after installing. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-05-19 07:01:35 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
AI generated
API
bank sync
budgeting
bug
can’t replicate
dependencies
docker
documentation
electron
experimental feature
feature
feedback
goal templates
good first issue
help wanted
importers
maintenance
needs info
needs testing
needs triage
needs votes
openid
payees
pull-request
Mirrored from GitHub Pull Request
 regression
reports
responsive
rules
schedules
server
✨ merged
split transactions
tech debt
tech-support
theme
transaction import
transaction reconciliation
transactions
translations
upstream
user interface
✅ approved
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/actual#82592
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?