You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Notify users when update available and allow them to update #85
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
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
Both of these seem completely reasonable to me from a user perspective! I would definitely not want it to seem like we're spamming people with update notifications if they're just trying to use the tool to get their work done and don't want to update right now.
Most of your laid out plan I agree with, @probablycorey.
3. Assumption 1 & 2 requires that we keep state somewhere. In order to reuse code I'm assuming we should reuse gh's config file.
We can do that for now, but ideally I would like us to save state elsewhere than our main config file. When gh's config file includes more useful configuration, and after we figure out how to securely save an OAuth token elsewhere than to this file, ~/.config/gh will theoretically become suitable and safe to check into version control by people who version their dotfiles, but if we keep updating it with a timestamp every 24h, then we break that use-case.
Closing since we've shipped a release that checks for and notifies about version upgrades!
The remaining work is around improving that mechanism (e.g. avoid checking too often, give concrete upgrade instructions such as “brew upgrade gh” when applicable, etc.), but these are going to be performed as follow-up tasks.
Activity
probablycorey commentedon Nov 19, 2019
Before I get too deep into this I wanted to validate some thinking. Here are some assumptions that might not be correct.
Based on that the logic of the "check for upgrade" flow would look like this...
@billygriffin @vilmibm @mislav should I change any of my assumptions? Am I overcomplicating this?
billygriffin commentedon Nov 20, 2019
Both of these seem completely reasonable to me from a user perspective! I would definitely not want it to seem like we're spamming people with update notifications if they're just trying to use the tool to get their work done and don't want to update right now.
probablycorey commentedon Nov 20, 2019
An example of how npm does this
mislav commentedon Nov 21, 2019
Most of your laid out plan I agree with, @probablycorey.
We can do that for now, but ideally I would like us to save state elsewhere than our main config file. When gh's config file includes more useful configuration, and after we figure out how to securely save an OAuth token elsewhere than to this file,
~/.config/ghwill theoretically become suitable and safe to check into version control by people who version their dotfiles, but if we keep updating it with a timestamp every 24h, then we break that use-case.mislav commentedon Dec 4, 2019
Closing since we've shipped a release that checks for and notifies about version upgrades!
The remaining work is around improving that mechanism (e.g. avoid checking too often, give concrete upgrade instructions such as “brew upgrade gh” when applicable, etc.), but these are going to be performed as follow-up tasks.