Looks like you and @Greebo have a good interim solution for the redis prefix, happy for that to be included.
I think we are still some way from fully automated update on non emonSD installs, updating service-runner manually to get there should be ok?
Il add the appending of the log.
Is there anything else I should consider? Im happy that this is ready otherwise.
I have put together a quick & temporary fix that simply looks for either of the 2 default prefixes used.
I just added a comment to the GitHub PR with a slight efficiency suggestion.
In my defence, it was a very quick bit of code 
…
I’ve commented on GitHub but this is an error I think.
Previously, the first if checks for a flag and if it exists does some stuff,
Now the ‘some stuff’ (line 50 on) is executed every time and ‘flag’ can be undefined or the previous value.
Ah yes, you’re right - I wasn’t paying sufficient attention to the indentation!
I’ve re-written parts of it today anyway to cope with multiple instances and any prefix - it does this by looking in redis for the “readapikey” key on startup and then uses any prefix(es) it finds there to subsequently search for service-runner.
It needs some more testing with a few different prefixes, and on a multi-instance install before its ready for a PR though. Until then, ignore my suggestions and go with @borpin’s original PR code.
@TrystanLea, is it safe to assume that every EmonCMS will have a “readapikey” key held in redis?
I like that 
Just did a pull on master and found the Server information when posted here is not formatted correctly. I’ve raised an issue.
Could this go into usefulscripts?
@borpin @Greebo I think it would be a good idea if we go forward with this v9.9.6 merge, the discussed changes to service-runner or associated emoncms calls can be updated at a later stage. The automated update process would at this point still be aimed at emonSD users. I think there is more work required to reach a point where clicking the update button on the UI works for custom installations - we can review and test these separately. I’ve tested the update on a emonpi here again and it all goes smoothly.
Test procedure:
SSH into stock EmonPi running emonSD-30Oct18
cd emonpi
git pull
git checkout service_correction
cd /var/www/emoncms
git checkout master
Then I login to the EmonPi, navigate to admin and running emonpi update.
Once emonpi:service_correction and emoncms:master are merged the update should work out of the box (without these manual changes) as the update procedure changes are all in 2nd level scripts (emoncmsupdate and emonhubupdate) called from the main “service-runner-update.sh” script that is in the emonpi repository.
@TrystanLea, I’m sorry for repeating myself, but it will be great if the Git tags can be set for each repository.
I think we have done all we can for now.
Great, ok Il start the process.
Emoncms Update, core and modules
Emoncms (v9.9.6):
Emonpi (v2.9.1):
emoncms app module (v1.2.1):
emoncms dashboard module (v1.3.3):
emoncms graph module (v1.2.2):
emoncms wifi module (v1.3.1):
emoncms device module (v1.2.1)
emoncms sync module (v1.0.1)
emoncms postprocess module (v1.0.0)
emoncms backup module (v1.1.6)
I think that’s all done! Thankyou everyone for helping with this release! 
Updating:
For emonPi & emonBase users the above is all available now by clicking emonPi/emonbase Update in the emoncms administration menu.
If you are running a custom installation of emoncms, feel free to update the core, or any specific module as you wish. There is still work ongoing on automating the update process for custom installations. Other than core and module updates the other main difference is the renaming of phpmqtt_input service to emoncms_mqtt service. This is a non breaking change as the original service is still present in the repository. See the readme here for details on how to remove the old mqtt_input service and install the new emoncms_mqtt service: emoncms/install-service-emoncmsmqtt.md at master · emoncms/emoncms · GitHub
@TrystanLea, something did not quite go as planned…
**Emoncms** Version low-write 9.9.6
Branch: * stable | Describe: 9.9.4-205-g22d2e6c1
Ok so, my bad. I must have translated my test commands badly. To get an annotated tag as opposed to a lightweight tag (which is what Github creates), you need to use the -a option. So
git tag -a 1.4 -m "my version 1.4"
I think that this can be fixed.
By using the command git log --pretty=oneline the last 2 commits to Stable are…
22d2e6c1c685982afe4deb17b17921df7b84cb2f Merge pull request #1159 from emoncms/master
53991d68e7c7e5ffc4c494ed2c7da6e350abef9a Update version.txt
And the last few commits to master are
0a74cda9c3d0b1fbf02a68b3c53b7bbdddf7612f readme for emoncms_mqtt service
acbfca04d932e093babc13bbdb71d689e425c83f Update version.txt
ede160083a24f7cc32f6b2026f187157d43bfe97 Update version.txt
53991d68e7c7e5ffc4c494ed2c7da6e350abef9a Update version.txt
The lightweight tag 9.9.6 currently points to this commit
# git show 9.9.6
commit acbfca04d932e093babc13bbdb71d689e425c83f
Author: Trystan Lea <[email protected]>
Date: Tue Feb 12 15:07:13 2019 +0000
Update version.txt
diff --git a/version.txt b/version.txt
index d9e3b748..709d3278 100644
--- a/version.txt
+++ b/version.txt
@@ -1 +1 @@
-9.9.7-beta
+9.9.6
The problem is this commit is not actually in stable…
I Think the command;
git tag -a -f 9.9.6 <commit> -m "The release message"
will set the tag correctly and override any meta data held against it. We just need to pick the right commit number.
You do need to then push the tag as in
git push origin 9.9.6
Alternatively we leave it and try again next time 