Proposal: occassionally show available upgrades for Krew

[ahmetb]

With our current user experience, users can install krew once, then keep installing plugins every week, but it may never occur to them to upgrade krew to a newer version. This leaves a lot of users on older versions.

With the addition of #457 at least we now show upgrades available for installed plugins when an index update happens (e.g. directly through "krew update" or indirectly via "krew install").

What if we did a silent "freshness check" for Krew that ran only 30-40% of the time and showed the users available updates?

e.g.

func main(){
  if rand() < 0.3 {
    go checkAvailableUpdates()
  }
  
  // existing functionality

  if updateAvailable() { printUpdateReminder() }
}

We can find the latest version through something simple, like Go equivalent of curl --silent https://api.github.com/repositories/138544269/releases/latest | jq -r .tag_name.

This design has several benefits:

• fire & forget: completes only on commands that take a while (slows down nothing) e.g. install
• since it is run rarely, it won't hit the api quota
• if it fails, ignore silently (e.g. firewall, github shut down in the future)
• print result only if krew output is successful (don't confuse user)

Earlier we do this the better: More users will get on the release train rather than staying in older versions for a long time (not that it's too harmful).

Thoughts appreciated.
cc: @corneliusweig @artmello
/kind proposal
/area distribution

[corneliusweig]

I'm supportive of this.

My main reason is that people are used to keep their systems up to date. But if somebody is unaware of the fact that krew manages itselft, one might forget to update krew once in a while [1]. So this totally makes sense to me.
Also, I don't think that it will be too annoying, because the message won't show up if you upgrade krew to the latest version.

It's very tempting to use this for tracking how many active users krew has. But I think many users would be allergic to that, so let's not do it. So using github API is the best approach, because we won't have access to those data.

For better control over the feature, there should be a (hidden?) flag to disable or force the check. This will be essential for integration testing.

[1] war story: I met some krew users the other day who had not yet done the receipts migration.

[artmello]

+1 for this.

About the frequency, should instead of (or maybe together with) checking in a defined percentage, could we add a time frame to skip the checks? Something like, if the check was executed on last X days do not execute it again.

Also, what to do if we discover that there is a new version but the user did not upgrade Krew? Should we notify it again every time or will user have some way to say "skip this update"? Should we keep looking for new versions if we know that there is a new one and installed version did not change (i.e. tell user which is the last version available)?

[ahmetb]

So using github API is the best approach, because we won't have access to those data.

Yes "phoning home" will be a no-go for many people, but today Krew uses github anyway, so this is not anything new. Plus it will not send any more PII than the IP address (which it already does).

For better control over the feature, there should be a (hidden?) flag to disable or force the check. This will be essential for integration testing.

We should absolutely introduce a way to disable upgrade checks. Until we have a config file (which we'll most likely have as part of #23) we can introduce an environment variable opt-out.

[ahmetb]

Also, what to do if we discover that there is a new version but the user did not upgrade Krew? Should we notify it again every time or will user have some way to say "skip this update"?

@artmello I tend to keep things simple, so we might choose to not even offer that option. We can reduce the % it will be checked, and people don't run krew 10 times a day (it's more like 2/month) so it's not a problem maybe.

[corneliusweig]

Making the upgrade check smart by considering if it had run before would mean that we need some kind of persistence. That will make it more complicated, so let's not do that right now.

Anyway, I'm thinking why not perform the check every time and not just every 40% or so. For one, this would make krew's behavior more consistent. And additionally, it would ensure that infrequent users are more likely to receive the notification (because it should still run in its go-routine and not block if the main logic has already completed).

[ahmetb]

@corneliusweig the problem would be a journey such as "krew search" → "krew install" → "krew info" → "krew remove" would show the upgrade notification 4 times back-to-back (to the extent where it would annoy users to ask for a "disable upgrade notification" feature).

Another option is to save a sentinel file somewhere (e.g. $TEMPDIR/krew/last_update_checked) so we check it either once every reboot, or every 7 days computed from the date saved in this file? Both of these options sound reasonable to me.