Fwd: [openvehicles/Open-Vehicle-Monitoring-System-3] 29e333: Issue #36: Add support for ota/tag in config
A few changes to OTA this morning: The ‘ota status’ command used to check available server version only if a WIFI network was up. It now does that if ANY network is up (including modem). I’ve added a config instance ‘tag’ to parameter ‘ota’. This can be used to override the ota tag (default: main) at run-time. I’ve added a config instance ‘server’ to parameter ‘ota’. This can be used to override the ota server URL (default: api.openvehicles.com/firmware/ota <http://api.openvehicles.com/firmware/ota>). From now on, I’m going to be maintaining two tags for the production ota server api.openvehicles.com <http://api.openvehicles.com/>. These are: main: for stable releases edge: for bleeding edge developer releases You can, for example, now set your module to bleeding-edge by ‘config set ota tag edge’. Regards, Mark.
Begin forwarded message:
From: GitHub <noreply@github.com> Subject: [openvehicles/Open-Vehicle-Monitoring-System-3] 29e333: Issue #36: Add support for ota/tag in config Date: 16 April 2018 at 8:37:46 AM HKT To: mark@webb-johnson.net Reply-To: GitHub <noreply@github.com>
Branch: refs/heads/master Home: https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3 Commit: 29e33348f6dff949fd22567083de1d9db04b05e3 https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/29e3... Author: Mark Webb-Johnson <mark@webb-johnson.net> Date: 2018-04-16 (Mon, 16 Apr 2018)
Changed paths: M vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp M vehicle/OVMS.V3/main/ovms_version.cpp
Log Message: ----------- Issue #36: Add support for ota/tag in config Issue #37: Add support for ota/server in config Issue #38: ota status should show available server version for modem as well as wifi
On Mon, 16 Apr 2018, Mark Webb-Johnson wrote:
From now on, I’m going to be maintaining two tags for the production ota server api.openvehicles.com <http://api.openvehicles.com/>. These are:
main: for stable releases edge: for bleeding edge developer releases
Why not the "standard" terms release (or stable), beta, alpha? -- Steve
The original idea was to have these as release tags that users could subscribe to. The factory firmware we have has everyone as ‘main’, so that one is hard to change. I did consider ‘alpha’, but it just looked strange to me. The idea is that ‘edge’ will be an automated (at least) nightly build. I think there is room for one more like Tesla’s ‘early access program’ (pre-release candidates that should be stable but have not had widescale testing). So, my overall suggestion is for something like: main eap edge Steve’s alternative would be: main beta alpha Other than ‘main’, these are simple to change. Happy to go with the consensus... Regards, Mark.
On 16 Apr 2018, at 9:26 AM, Stephen Casner <casner@acm.org> wrote:
On Mon, 16 Apr 2018, Mark Webb-Johnson wrote:
From now on, I’m going to be maintaining two tags for the production ota server api.openvehicles.com <http://api.openvehicles.com/>. These are:
main: for stable releases edge: for bleeding edge developer releases
Why not the "standard" terms release (or stable), beta, alpha?
-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Another point perhaps missed is that these are really release tags, not necessarily developer release stages. So, for example, say we were working on a branch with a major re-write called v4.x, we could create a ‘v4x’ branch (or whatever) and release ota updates to it. Modules subscribing to that tag would get those updates. I guess we could address that with v3-beta, v3-alpha, v4-alpha, etc. Regards, Mark
On 16 Apr 2018, at 9:40 AM, Mark Webb-Johnson <mark@webb-johnson.net> wrote:
The original idea was to have these as release tags that users could subscribe to. The factory firmware we have has everyone as ‘main’, so that one is hard to change.
I did consider ‘alpha’, but it just looked strange to me.
The idea is that ‘edge’ will be an automated (at least) nightly build.
I think there is room for one more like Tesla’s ‘early access program’ (pre-release candidates that should be stable but have not had widescale testing). So, my overall suggestion is for something like:
main eap edge
Steve’s alternative would be:
main beta alpha
Other than ‘main’, these are simple to change. Happy to go with the consensus...
Regards, Mark.
On 16 Apr 2018, at 9:26 AM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
On Mon, 16 Apr 2018, Mark Webb-Johnson wrote:
From now on, I’m going to be maintaining two tags for the production ota server api.openvehicles.com <http://api.openvehicles.com/> <http://api.openvehicles.com/ <http://api.openvehicles.com/>>. These are:
main: for stable releases edge: for bleeding edge developer releases
Why not the "standard" terms release (or stable), beta, alpha?
-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
"alpha" / "beta" imply some underlying development & release plan, i.e. a list of features to be reached for the "release" version. "stable" and "nightly" are also used, but "nightly" implies a fixed schedule -- I'd rather have the option to update manually several times a day --, and "stable" implies some sort of quality check / warranty, which we also cannot provide. So I think "main" and "edge" are appropriate. Regards, Michael Am 16.04.2018 um 03:46 schrieb Mark Webb-Johnson:
Another point perhaps missed is that these are really release tags, not necessarily developer release stages. So, for example, say we were working on a branch with a major re-write called v4.x, we could create a ‘v4x’ branch (or whatever) and release ota updates to it. Modules subscribing to that tag would get those updates.
I guess we could address that with v3-beta, v3-alpha, v4-alpha, etc.
Regards, Mark
On 16 Apr 2018, at 9:40 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
The original idea was to have these as release tags that users could subscribe to. The factory firmware we have has everyone as ‘main’, so that one is hard to change.
I did consider ‘alpha’, but it just looked strange to me.
The idea is that ‘edge’ will be an automated (at least) nightly build.
I think there is room for one more like Tesla’s ‘early access program’ (pre-release candidates that should be stable but have not had widescale testing). So, my overall suggestion is for something like:
* main * eap * edge
Steve’s alternative would be:
* main * beta * alpha
Other than ‘main’, these are simple to change. Happy to go with the consensus...
Regards, Mark.
On 16 Apr 2018, at 9:26 AM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
On Mon, 16 Apr 2018, Mark Webb-Johnson wrote:
From now on, I’m going to be maintaining two tags for the production ota server api.openvehicles.com <http://api.openvehicles.com/> <http://api.openvehicles.com/>. These are:
main: for stable releases edge: for bleeding edge developer releases
Why not the "standard" terms release (or stable), beta, alpha?
-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
To try to avoid a repeat of the 3.1.007 issue with OTA updates, I’ve set things up as below: edge: Bleeding edge developer, built automatically each night with 3.1.XXX-N-HHHHHH style versioning eap: Early Access Program pre-releases, usually with 3.1.XXX style versioning main: Stable releases that have completed testing in EAP, with 3.1.XXX style versioning. Before moving things edge -> eap, I’ll have a checklist of regression tests to run (including ota update). Other functional problems should have been picked up by developer cars while in ‘edge’ release. I suggest to leave a particular build in ‘edge’ for a week, to make sure no problems reported to those early real-world testers, before moving to ‘main’. I have an automated nightly build script that runs at 4pm UTC (midnight HKT). That pulls the latest masters for esp-idf and ovms firmware, then builds as appropriate. If there is something to build (something in git changed), it does it automatically and produces an email summary like this: Subject: OVMS Nightly Firmware Build 3.1.008-13-g272697e 3.1.008-13-g272697e Thu Jun 28 00:57:19 UTC 2018 Automated build (markhk8) Total sizes: DRAM .data size: 17116 bytes DRAM .bss size: 33536 bytes Used static DRAM: 50652 bytes ( 130084 available, 28.0% used) Used static IRAM: 102096 bytes ( 28976 available, 77.9% used) Flash code: 1279002 bytes Flash rodata: 598168 bytes Total image size:~1996382 bytes (.bin may be padded larger) * 272697e (HEAD, origin/master, origin/HEAD, master) Twizy: no sufficient level info on charge done * 8497d9f Web dashboard: range display min/max exchanged * 5d8f96d Webserver: fix u64 alignment * 5363ab8 TeslaRoadster: Vehicle cooldown command and implementation * bf3b0d5 TeslaRoadster: Digital Speedo implementation * d0221bf TeslaRoadster: Refuse to lock a car that is ON * 7179600 Update project status files * b3bef78 TeslaRoadster: Digital Speedo implementation * cfbd297 TeslaRoadster: Vehicle cooldown command and implementation * ec4bc37 Add VehicleModeKey helper function At the moment, that summary comes to me. Is there any use sending it to the ovmsdev mailing list? With developer cars set to ‘edge’, and automatically updating each night, hopefully with this three stage process we can pickup on problems before they hit the main stable trunk. Regards, Mark.
On 17 Apr 2018, at 4:35 AM, Michael Balzer <dexter@expeedo.de> wrote:
"alpha" / "beta" imply some underlying development & release plan, i.e. a list of features to be reached for the "release" version.
"stable" and "nightly" are also used, but "nightly" implies a fixed schedule -- I'd rather have the option to update manually several times a day --, and "stable" implies some sort of quality check / warranty, which we also cannot provide.
So I think "main" and "edge" are appropriate.
Regards, Michael
Am 16.04.2018 um 03:46 schrieb Mark Webb-Johnson:
Another point perhaps missed is that these are really release tags, not necessarily developer release stages. So, for example, say we were working on a branch with a major re-write called v4.x, we could create a ‘v4x’ branch (or whatever) and release ota updates to it. Modules subscribing to that tag would get those updates.
I guess we could address that with v3-beta, v3-alpha, v4-alpha, etc.
Regards, Mark
On 16 Apr 2018, at 9:40 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
The original idea was to have these as release tags that users could subscribe to. The factory firmware we have has everyone as ‘main’, so that one is hard to change.
I did consider ‘alpha’, but it just looked strange to me.
The idea is that ‘edge’ will be an automated (at least) nightly build.
I think there is room for one more like Tesla’s ‘early access program’ (pre-release candidates that should be stable but have not had widescale testing). So, my overall suggestion is for something like:
main eap edge
Steve’s alternative would be:
main beta alpha
Other than ‘main’, these are simple to change. Happy to go with the consensus...
Regards, Mark.
On 16 Apr 2018, at 9:26 AM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
On Mon, 16 Apr 2018, Mark Webb-Johnson wrote:
From now on, I’m going to be maintaining two tags for the production ota server api.openvehicles.com <http://api.openvehicles.com/> <http://api.openvehicles.com/ <http://api.openvehicles.com/>>. These are:
main: for stable releases edge: for bleeding edge developer releases
Why not the "standard" terms release (or stable), beta, alpha?
-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Would this structure have helped in finding the ota issue? I mean, are there any developers updating ota from the "edge" releases instead of building themselves? Up to now I followed the approach of testing locally and only releasing to "edge" what works on my module, as "edge" is what beta testers are updating from now. If there are developers that update ota: The new structure means beta testers need to change their setup. I suggest introducing a "nightly" for developers instead, placed before "edge". To harmonize "edge" releases, I also need to know which commits are moved into "edge" then. Up to now we used the "3.1.xxx" version tagging for main releases, you seem to have changed this now with "3.1.008", as the tag is already set but the server still has 3.1.006 in the "main" directory. I suggest sticking to the main version tagging as before, as Github uses these to create "releases" (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases), and adding "3.1.xxx-n-hhhhhh" tags for the "edge" releases. Regards, Michael Am 28.06.2018 um 03:14 schrieb Mark Webb-Johnson:
To try to avoid a repeat of the 3.1.007 issue with OTA updates, I’ve set things up as below:
* edge: Bleeding edge developer, built automatically each night with 3.1.XXX-N-HHHHHH style versioning * eap: Early Access Program pre-releases, usually with 3.1.XXX style versioning * main: Stable releases that have completed testing in EAP, with 3.1.XXX style versioning.
Before moving things edge -> eap, I’ll have a checklist of regression tests to run (including ota update). Other functional problems should have been picked up by developer cars while in ‘edge’ release. I suggest to leave a particular build in ‘edge’ for a week, to make sure no problems reported to those early real-world testers, before moving to ‘main’.
I have an automated nightly build script that runs at 4pm UTC (midnight HKT). That pulls the latest masters for esp-idf and ovms firmware, then builds as appropriate. If there is something to build (something in git changed), it does it automatically and produces an email summary like this:
Subject: OVMS Nightly Firmware Build 3.1.008-13-g272697e
3.1.008-13-g272697e Thu Jun 28 00:57:19 UTC 2018 Automated build (markhk8)
Total sizes: DRAM .data size: 17116 bytes DRAM .bss size: 33536 bytes Used static DRAM: 50652 bytes ( 130084 available, 28.0% used) Used static IRAM: 102096 bytes ( 28976 available, 77.9% used) Flash code: 1279002 bytes Flash rodata: 598168 bytes Total image size:~1996382 bytes (.bin may be padded larger)
* 272697e (HEAD, origin/master, origin/HEAD, master) Twizy: no sufficient level info on charge done * 8497d9f Web dashboard: range display min/max exchanged * 5d8f96d Webserver: fix u64 alignment * 5363ab8 TeslaRoadster: Vehicle cooldown command and implementation * bf3b0d5 TeslaRoadster: Digital Speedo implementation * d0221bf TeslaRoadster: Refuse to lock a car that is ON * 7179600 Update project status files * b3bef78 TeslaRoadster: Digital Speedo implementation * cfbd297 TeslaRoadster: Vehicle cooldown command and implementation * ec4bc37 Add VehicleModeKey helper function
At the moment, that summary comes to me. Is there any use sending it to the ovmsdev mailing list?
With developer cars set to ‘edge’, and automatically updating each night, hopefully with this three stage process we can pickup on problems before they hit the main stable trunk.
Regards, Mark.
On 17 Apr 2018, at 4:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
"alpha" / "beta" imply some underlying development & release plan, i.e. a list of features to be reached for the "release" version.
"stable" and "nightly" are also used, but "nightly" implies a fixed schedule -- I'd rather have the option to update manually several times a day --, and "stable" implies some sort of quality check / warranty, which we also cannot provide.
So I think "main" and "edge" are appropriate.
Regards, Michael
Am 16.04.2018 um 03:46 schrieb Mark Webb-Johnson:
Another point perhaps missed is that these are really release tags, not necessarily developer release stages. So, for example, say we were working on a branch with a major re-write called v4.x, we could create a ‘v4x’ branch (or whatever) and release ota updates to it. Modules subscribing to that tag would get those updates.
I guess we could address that with v3-beta, v3-alpha, v4-alpha, etc.
Regards, Mark
On 16 Apr 2018, at 9:40 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
The original idea was to have these as release tags that users could subscribe to. The factory firmware we have has everyone as ‘main’, so that one is hard to change.
I did consider ‘alpha’, but it just looked strange to me.
The idea is that ‘edge’ will be an automated (at least) nightly build.
I think there is room for one more like Tesla’s ‘early access program’ (pre-release candidates that should be stable but have not had widescale testing). So, my overall suggestion is for something like:
* main * eap * edge
Steve’s alternative would be:
* main * beta * alpha
Other than ‘main’, these are simple to change. Happy to go with the consensus...
Regards, Mark.
On 16 Apr 2018, at 9:26 AM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
On Mon, 16 Apr 2018, Mark Webb-Johnson wrote:
From now on, I’m going to be maintaining two tags for the production ota server api.openvehicles.com <http://api.openvehicles.com/> <http://api.openvehicles.com/>. These are:
main: for stable releases edge: for bleeding edge developer releases
Why not the "standard" terms release (or stable), beta, alpha?
-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Short story: what do people want: nightly edge main or edge eap main ? Long story:
Would this structure have helped in finding the ota issue? I mean, are there any developers updating ota from the "edge" releases instead of building themselves?
There seem to be. I had a few download 3.1.007 from my server. I have two cars on “edge”. Developers actively working on things generally have it in factory and just flash that directly. But developers just running it in their cars seem to use OTA. The problem we had this time was that “edge” wasn’t actually built nightly as originally intended (just on-demand, and relatively infrequently) so I didn’t ota update from it and didn’t catch the problem until a few other cars on “edge” had already hit it. If “edge” had seen “3.1.007”, then ‘3.1.007-1”, then “3.1.007-2”, I (and maybe others) would have noticed the problem.
The new structure means beta testers need to change their setup. I suggest introducing a "nightly" for developers instead, placed before "edge”.
As I said before, I am happy to go with the consensus with this. My original plan (in that email back in April) was for: main eap edge The idea then was that “edge” was “bleeding edge” (nightly builds). “eap” and “main” were more formal release levels. And that is simply what I implemented now. At this stage it is very easy to change the names of “edge” and “eap” to whatever we want. It can be “main”, “edge”, and “nightly” (with “edge” taking on the role of “eap”), but that is different to what was original suggested back in April ("The idea is that ‘edge’ will be an automated (at least) nightly build”). As I said before, I am happy to go with the consensus on this. I haven’t announced anything, and the user guide is pending update on this, so we can do whatever we want now.
To harmonize "edge" releases, I also need to know which commits are moved into "edge" then. Up to now we used the "3.1.xxx" version tagging for main releases, you seem to have changed this now with "3.1.008", as the tag is already set but the server still has 3.1.006 in the "main" directory.
I think you can poll “ovms.ver” from edge/, eap/, and main/ to see. Or we can arrange rsync, email notification, or something else? The nightly build system produces a git log in ovms.ver (the last 10 commits). I think that "3.1.008-13-g272697e” (for example) means 13 commits beyond 3.1.008, and the “g272697e” is the commit hash show in the log. Today (I just checked), we have: “edge” has 3.1.008-15-g0631a2 “eap” has 3.1.008 “main” has 3.1.006 That seems correct. We have 3.1.008 in “eap” for a few days, to ensure it doesn’t cause any problems. It seems ok, so should go to “main” later this weekend (and which point we’ll be over the 3.1.007 mess).
I suggest sticking to the main version tagging as before, as Github uses these to create "releases" (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases>), and adding "3.1.xxx-n-hhhhhh" tags for the "edge" releases.
I am using the tags from our existing build system ("git describe --always --tags --dirty”). As “edge” is a nighty (or on-demand) build, it will see version tags between tagged (3.1.XXX) formal main releases and these will appear as “3.1.xxx-n-hhhhhh”. The idea is that when we decide to release a tagged formal main release (3.1.XXX), we will tag it, push the tags, and then do a manual build on “edge”. A few days go by, and if no issues are found that 3.1.XXX release is copied over to “eap”. We then wait a few days (perhaps a week) to ensure no problems reported, and finally move the same “3.1.XXX” to “main”. During that time, “edge” may have progressed from 3.1.XXX to 3.1.XXX-1, to 3.1.XXX-2, etc. The “eap” and “main” should only ever see “3.1.XXX” and that should have been running on cars, and been updated from, by the time the firmware gets to “eap”/“main”. Regards, Mark.
On 30 Jun 2018, at 3:40 PM, Michael Balzer <dexter@expeedo.de> wrote:
Would this structure have helped in finding the ota issue? I mean, are there any developers updating ota from the "edge" releases instead of building themselves?
Up to now I followed the approach of testing locally and only releasing to "edge" what works on my module, as "edge" is what beta testers are updating from now.
If there are developers that update ota:
The new structure means beta testers need to change their setup. I suggest introducing a "nightly" for developers instead, placed before "edge".
To harmonize "edge" releases, I also need to know which commits are moved into "edge" then. Up to now we used the "3.1.xxx" version tagging for main releases, you seem to have changed this now with "3.1.008", as the tag is already set but the server still has 3.1.006 in the "main" directory.
I suggest sticking to the main version tagging as before, as Github uses these to create "releases" (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/releases>), and adding "3.1.xxx-n-hhhhhh" tags for the "edge" releases.
Regards, Michael
Am 28.06.2018 um 03:14 schrieb Mark Webb-Johnson:
To try to avoid a repeat of the 3.1.007 issue with OTA updates, I’ve set things up as below:
edge: Bleeding edge developer, built automatically each night with 3.1.XXX-N-HHHHHH style versioning eap: Early Access Program pre-releases, usually with 3.1.XXX style versioning main: Stable releases that have completed testing in EAP, with 3.1.XXX style versioning.
Before moving things edge -> eap, I’ll have a checklist of regression tests to run (including ota update). Other functional problems should have been picked up by developer cars while in ‘edge’ release. I suggest to leave a particular build in ‘edge’ for a week, to make sure no problems reported to those early real-world testers, before moving to ‘main’.
I have an automated nightly build script that runs at 4pm UTC (midnight HKT). That pulls the latest masters for esp-idf and ovms firmware, then builds as appropriate. If there is something to build (something in git changed), it does it automatically and produces an email summary like this:
Subject: OVMS Nightly Firmware Build 3.1.008-13-g272697e
3.1.008-13-g272697e Thu Jun 28 00:57:19 UTC 2018 Automated build (markhk8)
Total sizes: DRAM .data size: 17116 bytes DRAM .bss size: 33536 bytes Used static DRAM: 50652 bytes ( 130084 available, 28.0% used) Used static IRAM: 102096 bytes ( 28976 available, 77.9% used) Flash code: 1279002 bytes Flash rodata: 598168 bytes Total image size:~1996382 bytes (.bin may be padded larger)
* 272697e (HEAD, origin/master, origin/HEAD, master) Twizy: no sufficient level info on charge done * 8497d9f Web dashboard: range display min/max exchanged * 5d8f96d Webserver: fix u64 alignment * 5363ab8 TeslaRoadster: Vehicle cooldown command and implementation * bf3b0d5 TeslaRoadster: Digital Speedo implementation * d0221bf TeslaRoadster: Refuse to lock a car that is ON * 7179600 Update project status files * b3bef78 TeslaRoadster: Digital Speedo implementation * cfbd297 TeslaRoadster: Vehicle cooldown command and implementation * ec4bc37 Add VehicleModeKey helper function
At the moment, that summary comes to me. Is there any use sending it to the ovmsdev mailing list?
With developer cars set to ‘edge’, and automatically updating each night, hopefully with this three stage process we can pickup on problems before they hit the main stable trunk.
Regards, Mark.
On 17 Apr 2018, at 4:35 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
"alpha" / "beta" imply some underlying development & release plan, i.e. a list of features to be reached for the "release" version.
"stable" and "nightly" are also used, but "nightly" implies a fixed schedule -- I'd rather have the option to update manually several times a day --, and "stable" implies some sort of quality check / warranty, which we also cannot provide.
So I think "main" and "edge" are appropriate.
Regards, Michael
Am 16.04.2018 um 03:46 schrieb Mark Webb-Johnson:
Another point perhaps missed is that these are really release tags, not necessarily developer release stages. So, for example, say we were working on a branch with a major re-write called v4.x, we could create a ‘v4x’ branch (or whatever) and release ota updates to it. Modules subscribing to that tag would get those updates.
I guess we could address that with v3-beta, v3-alpha, v4-alpha, etc.
Regards, Mark
On 16 Apr 2018, at 9:40 AM, Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> wrote:
The original idea was to have these as release tags that users could subscribe to. The factory firmware we have has everyone as ‘main’, so that one is hard to change.
I did consider ‘alpha’, but it just looked strange to me.
The idea is that ‘edge’ will be an automated (at least) nightly build.
I think there is room for one more like Tesla’s ‘early access program’ (pre-release candidates that should be stable but have not had widescale testing). So, my overall suggestion is for something like:
main eap edge
Steve’s alternative would be:
main beta alpha
Other than ‘main’, these are simple to change. Happy to go with the consensus...
Regards, Mark.
On 16 Apr 2018, at 9:26 AM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
On Mon, 16 Apr 2018, Mark Webb-Johnson wrote: > From now on, I’m going to be maintaining two tags for the production > ota server api.openvehicles.com <http://api.openvehicles.com/> <http://api.openvehicles.com/ <http://api.openvehicles.com/>>. These > are: > > main: for stable releases > edge: for bleeding edge developer releases
Why not the "standard" terms release (or stable), beta, alpha?
-- Steve_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26 _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
On Mon, Apr 16, 2018 at 09:13:33AM +0800, Mark Webb-Johnson wrote:
A few changes to OTA this morning:
The ‘ota status’ command used to check available server version only if a WIFI network was up. It now does that if ANY network is up (including modem).
I’ve added a config instance ‘tag’ to parameter ‘ota’. This can be used to override the ota tag (default: main) at run-time.
Something unexpected happens if the server/version/tag doesn't exist: OVMS# ota status Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.004-193-g0d5cc93/ota_1/ro2 (build idf v3.1-dev-454-gdaef4b5c May 11 2018 07:58:30) Server Available: <!DOCTYPE html> (is newer) <head> <meta charset="utf-8" /> <link rel="shortcut icon" href="http://api.openvehicles.com/sites/default/files/favicon_0.ico" type="image/vnd.microsoft.icon" /> <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" /> <title>Page not found | Open Vehicles</title> ... followed by a couple more pages of html, including: <div class="content"> The requested page "/firmware/ota/v3.1/ro2/ovms3.ver" could not be found. </div> Fair enough that it didn't find an update as I'm using my own unique CONFIG_OVMS_VERSION_TAG "ro2", but it shouldn't mistake the html error page as a valid result. Suggested fix: diff --git a/vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp b/vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp index 226f502..9ed0b6a 100644 --- a/vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp +++ b/vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp @@ -586,7 +586,7 @@ void OvmsOTA::GetStatus(ota_info& info, bool check_update /*=true*/) url.append("/ovms3.ver"); OvmsHttpClient http(url); - if (http.IsOpen() && http.BodyHasLine()) + if (http.IsOpen() && http.ResponseCode() == 200 && http.BodyHasLine()) { info.version_server = http.BodyReadLine(); char rbuf[512];
Nice. I like it when problems are reported with the fix. Thanks. Committed fix. Regards, Mark.
On 11 May 2018, at 4:34 PM, Robin O'Leary <ovmsdev@caederus.org> wrote:
On Mon, Apr 16, 2018 at 09:13:33AM +0800, Mark Webb-Johnson wrote:
A few changes to OTA this morning:
The ‘ota status’ command used to check available server version only if a WIFI network was up. It now does that if ANY network is up (including modem).
I’ve added a config instance ‘tag’ to parameter ‘ota’. This can be used to override the ota tag (default: main) at run-time.
Something unexpected happens if the server/version/tag doesn't exist:
OVMS# ota status Running partition: ota_1 Boot partition: ota_1 Firmware: 3.1.004-193-g0d5cc93/ota_1/ro2 (build idf v3.1-dev-454-gdaef4b5c May 11 2018 07:58:30) Server Available: <!DOCTYPE html> (is newer)
<head> <meta charset="utf-8" /> <link rel="shortcut icon" href="http://api.openvehicles.com/sites/default/files/favicon_0.ico" type="image/vnd.microsoft.icon" /> <meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1" /> <title>Page not found | Open Vehicles</title>
... followed by a couple more pages of html, including:
<div class="content"> The requested page "/firmware/ota/v3.1/ro2/ovms3.ver" could not be found. </div>
Fair enough that it didn't find an update as I'm using my own unique CONFIG_OVMS_VERSION_TAG "ro2", but it shouldn't mistake the html error page as a valid result.
Suggested fix:
diff --git a/vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp b/vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp index 226f502..9ed0b6a 100644 --- a/vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp +++ b/vehicle/OVMS.V3/components/ovms_ota/src/ovms_ota.cpp @@ -586,7 +586,7 @@ void OvmsOTA::GetStatus(ota_info& info, bool check_update /*=true*/) url.append("/ovms3.ver");
OvmsHttpClient http(url); - if (http.IsOpen() && http.BodyHasLine()) + if (http.IsOpen() && http.ResponseCode() == 200 && http.BodyHasLine()) { info.version_server = http.BodyReadLine(); char rbuf[512]; _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
participants (4)
-
Mark Webb-Johnson -
Michael Balzer -
Robin O'Leary -
Stephen Casner