devblog
This commit is contained in:
parent
e2f17e9da3
commit
ca5f0cdf85
1 changed files with 22 additions and 0 deletions
22
doc/devblog/day_62__upgrade_alerts.mdwn
Normal file
22
doc/devblog/day_62__upgrade_alerts.mdwn
Normal file
|
@ -0,0 +1,22 @@
|
|||
Still working on the git repair code. Improved the test suite, which found
|
||||
some more bugs, and so I've been running tests all day and occasionally
|
||||
going and fixing a bug in the repair code. The hardest part of repairing a
|
||||
git repo has turned out to be reliably determining which objects in it are
|
||||
broken. Bugs in git don't help (but the git devs are going to fix the one I
|
||||
reported).
|
||||
|
||||
But the interesting new thing today is that I added some upgrade alert code
|
||||
to the webapp. Ideally everyone would get git-annex and other software as
|
||||
part of an OS distribution, which would include its own upgrade system --
|
||||
But the [survey](http://git-annex-survey.branchable.com/polls/2013/how_installed/)
|
||||
tells me that a quarter of installs are from the prebuilt binaries I
|
||||
distribute.
|
||||
|
||||
So, those builds are going to be built with knowledge of an upgrade url,
|
||||
and will periodically download a small info file (over https) to see if a
|
||||
newer version is available, and show an alert.
|
||||
|
||||
I think all that's working, though I have not yet put the info files in
|
||||
place and tested it. The actual upgrade process will be a manual
|
||||
download and reinstall, to start with, and then perhaps I'll automate it
|
||||
further, depending on how hard that is on the different platforms.
|
Loading…
Add table
Reference in a new issue