Before I get too deep into this I wanted to validate some thinking. Here are some assumptions that might not be correct.

To avoid adding extra time to each execution, we will only check for a new release after X hours have passed.
We don't want to remind the user after each execution that there is a new version available, show the message once every X hours
Assumption 1 & 2 requires that we keep state somewhere. In order to reuse code I'm assuming we should reuse gh's config file.

Based on that the logic of the "check for upgrade" flow would look like this...

There are three flags, UPGRADE_CHECKED_AT, UPGRADE_VERSION, and UPGRADE_REMINDED_AT

- if not tty, exit
- Get the current version
- if current version == UPGRADE_VERSION exit
- if UPGRADE_REMINDED_AT is set and is less than 24 hours old, exit
- if UPGRADE_REMINDED_AT is set and more than 24 hours old, ping the user, update UPGRADE_REMINDED_AT and exit

- if UPGRADE_CHECKED_AT < 24 hours exit
- Get the released version
- update UPGRADE_CHECKED_AT and UPGRADE_VERSION
- If the current version equals the released version exit

@billygriffin @vilmibm @mislav should I change any of my assumptions? Am I overcomplicating this?

Notify users when update available and allow them to update #85

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions