Soko, From the original announcement on this: 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. This is all from ‘master’ and unrelated to braches (which are experimental and usually hand-built).
https://www.openvehicles.com/node/2592 shows v3.2.015 since a couple of minutes. Is this the "main” channel
Usually, unless we explicitly say ’to early access program’.
changes.txt shows v3.2.015 for 2nd of Sep. Website says 8th…
The v3.2.015 code was fixed and tagged on 2nd Sep, then release to EAP. It went to MAIN on 8th Sep (after EAP testing). Regards, Mark
On 8 Sep 2020, at 3:47 PM, Soko <ovms@soko.cc> wrote:
Hey guys,
I'm wondering a while now how the firmware release process is working in OVMS.
I have found in the OVMS settings that I can choose "main", "eap" or "edge" as the update channel...
How does this relate to the github branches?
https://www.openvehicles.com/node/2592 shows v3.2.015 since a couple of minutes. Is this the "main" channel? VWUP.OBD is not listed there... but in the user docs it is already: https://docs.openvehicles.com/en/latest/components/vehicle_vweup_obd/docs/in...
changes.txt shows v3.2.015 for 2nd of Sep. Website says 8th...
Not that all the details here need to be perfectly matching. Was just wondering about a coarse grained info about the process...
thanks
Soko
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev