Update warning

[jbenet]

ipfs command should check for updates from github and warn the user. This should be able to be changed in the config. Maybe:

• update.check ignore Do not check.
• update.check warn (default) Warn the user on every run of the ipfs command.
• update.check error Warn the user on every run of the ipfs command, and exit.

(So, changed with ipfs config update.check ignore. )

[jbenet]

Maybe:

Long/Obvious Error

Warning: You are running version X.X.X of go-ipfs. The latest version is Y.Y.Y. 
Since this is alpha software, it is strongly recommended you update. 

You can update go-ipfs by running

    ipfs version update

You can silence this message by running

    ipfs config update.check ignore

Short Error

Warning: You are running version X.X.X of go-ipfs. The latest version is Y.Y.Y.

[jbenet]

@cleichner

[dborzov]

Hey, @jbenet, should I chip in, or is it for @cleichner?

[cleichner]

You can absolutely chip in. I was just discussing this with @jbenet IRL.

[cryptix]

I'd consider using go-selfupdate but if it is just about warning/error for an update, using go-github's func (*RepositoriesService) ListReleases might be enough.

[dborzov]

@cleichner , great, tnx!

@cryptix , I think adding go-github to imports is an overkill, one HTTP request to the github's API should be more than enough. Or is there something I am missing?

Maybe we can make a stable branch for releases to compare the running version's commit hash against. If we pass the current commit's hash straight to the binary during the build process somehow, it will have been pretty cool. Don't know how is that possible with plain go build though.

Passing params as code literals is dangerous though, blink and you got yourself a C-style preprocessor :))

We probably should just look up project's most recent Github releases.

[cryptix]

@cryptix , I think adding go-github to imports is an overkill, one HTTP request to the github's API should be more than enough. Or is there something I am missing?

Point taken, I was just thinking about not repeating this and future-proofness maybe but Github wont break their API just like that most likely and it really is just a http.Get and json.Decode and since vendoring is also on the table, it really isn't worth it to include the whole github api.

[jbenet]

Best strategy would allow deploying a new release as a semver tag (say, 0.1.2). A stable or releases branch is also fine. I'd like to save Github releases for when we reach real, wider release points (e.g. once it's actually useful). We're close, but not there yet.

[whyrusleeping]

This is probably worth digging back up and thinking about again

[jbenet]

@dborzov got the update warning done in #31 (yay)

Remaining thing to do is make automatic upgrading work. I've detailed this in #169 and #170.