[Ovmsdev] Firmware release handling

[Mark Webb-Johnson]

Yes. They are built from a GitHub trigger.

> On 8 Sep 2020, at 5:15 PM, Soko <ovms at soko.cc> wrote:
> 
> 
> Thanks Mark, got it!
> 
> Just to be complete: The user docs are a live view of the master branch, correct?
> 
> Soko
> 
> On 08.09.2020 09:58, Mark Webb-Johnson wrote:
>> 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 at 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/index.html
>>> 
>>> 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 at lists.openvehicles.com
>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20200908/f456fc97/attachment.htm>