💡 [Feature Request] - Opt in Frappe Books update

[18alantom]

Summary

Give users the choice to update Frappe Books instead of auto-updating.

What problem are you trying to solve?

New releases might include bugs which functionally break Frappe Books for users. Without opt in updates the users can't use an older version of Frappe Books since it will auto update to the latest version.

The only workaround then is to firewall Frappe Books to prevent the update.

Basic Example

On update being available.

1. The user sees a dialog box that asks them if they'd like to update to the latest version.
2. On agreeing, the update downloads in the background and notifies user to restart when available.
3. On disagreeing, the update prompt is postponed to a later date.

Improvements to the above:

• Modal that shows the change log for the available update.
• Dismiss-able progress bar to view download progress in the lower right corner.
• Check for updates button in the settings.

References

• https://www.electronjs.org/docs/latest/api/auto-updater
• https://github.com/frappe/books/blob/master/main/registerAutoUpdaterListeners.ts

Drawbacks

• Users raising issues for older version bugs that may have been fixed in newer versions.
• Schema backward compatibility and data loss. There could be a check which prevents databases opened in certain versions to not be opened in certain older versions (version is stored under System Settings).

Note: updates used to initially be opt-in but it was removed due to certain version bumps involving large changes such that updating was imperative. Nevertheless, it was a bad choice.

Reference Issues

#808

Just a recent example, but any issue that breaks Frappe Books in a way that it wasn't previously broken comes under this.

[Isaac-GC]

@18alantom For an additional item that I think should be included in this are release tracks.

While there will be bugs in the normal release track, introducing a release track (i.e. beta channel), will allow users who are willing to test the latest version to be able to give feedback that helps address unforeseen bugs. In this way, the normal release track can have a more steady release cadence (i.e. once a month or so) whereas the beta release track will be as necessary. After everything looks nice-ish (not counting the million and one edge cases), we release then.

EDIT:
LMK your opinion on this, but I imagine possibly moving to a workflow like this would be the best:

[18alantom]

@Isaac-GC I am for the use of release tracks. It wasn't previously used due to low user count not warranting the overhead. I think now's an apt time to switch over.

W.r.t implementation, in the interest of simplicity, I'd go with just two release branches:

• master for cutting-edge/beta releases (on GitHub I'd mark these as pre-release)
• release for non-beta/monthly/bug-fix releases

In Books the user can check a flag that updates/notifies for beta releases too, without which beta releases are ignored.

That being said w.r.t workflow, the final call is yours.