[Ovmsdev] 3.2.018 release

[Mark Webb-Johnson]

The change is not too extensive, so I have made it (as hopefully the last in v3.2 branch).

On api.openvehicles.com <http://api.openvehicles.com/>, I have simply symlinked v3.3 to v3.1 for the moment (we can revisit this once we have reviewed the changes necessary to sdkconfig for ESP32 rev3 support). Remember that the v3.x part of the OTA paths reflects the hardware version, not necessarily firmware version.

I have copied this to ‘eap' on api.openvehicles.com <http://api.openvehicles.com/>.

I have made the branch ‘v3.2’, as a historical backup.

I have merged back for-v3.3 into master, and removed the for-v3.3 branch (so ‘edge’ should now build as this version).

I have tagged this new master as 3.3-001, and built edge on api.openvehicles.com <http://api.openvehicles.com/>.

I appreciate that this is a big change, so have freed up my evenings this week to try to get the remaining issues with v3.3 resolved, ready for release of this firmware to the factory around early December. I hope that this is not too impacting for those on ‘edge’ release, and any bugs / changes can be quickly addressed.

Regards, Mark.

> On 20 Nov 2021, at 11:24 PM, Michael Balzer <dexter at expeedo.de> wrote:
> 
> Signed PGP part
> Mark,
> 
> why not introduce this for v3.2 as well?
> 
> If a v3.3 user accidentally installs a v3.2 build, that would not heal automatically but stick until manually fixed.
> 
> I think it makes sense to have all builds automatically try to update to the best build available for the hardware in use.
> 
> Am I missing somehing?
> 
> Regards,
> Michael
> 
> 
> Am 19.11.21 um 02:44 schrieb Mark Webb-Johnson:
>> Regarding the 3.2.018, I will handle it this afternoon (my time).
>> 
>> Regarding OTA and support for rev3 ESP32, at the moment, the OTA URL is composed of:
>> 
>> <server> (default api.openvehicles.com/firmware/ota <http://api.openvehicles.com/firmware/ota>)
>> <base> (either /v3.0/ or /v3.1/ depending on CONFIG_OVMS_HW_BASE_3_0 or CONFIG_OVMS_HW_BASE_3_1
>> <tag> (default ‘main’)
>> /ovms3.ver
>> 
>> My suggestion is to add the hardware platform (as detected by the code that provides metric m.hardware) in there. Perhaps replace <base> with something that detects /v3.0/, /v3.1/, or /v3.3/ based on a combination of CONFIG_OVMS_HW_BASE and m.hardware ESP32 revision? We should probably just implement that in the v3.3 code, so v3.2 and before keep using CONFIG_OVMS_HW_BASE.
>> 
>> Regards, Mark.
>> 
>>> On 19 Nov 2021, at 5:24 AM, Michael Balzer <dexter at expeedo.de <mailto:dexter at expeedo.de>> wrote:
>>> 
>>> Signed PGP part
>>> Sounds OK for me.
>>> 
>>> Regarding using the platform revision instead of CONFIG_OVMS_HW_BASE_3_x config: so in case someone accidentally installs the wrong firmware, the system would heal itself by a simple OTA update? Sounds good and should be a simple change.
>>> 
>>> Regards,
>>> Michael
>>> 
>>> 
>>> Am 18.11.21 um 08:06 schrieb Mark Webb-Johnson:
>>>> 
>>>> We need to get the v3.3 release ready for release now, as the new v3.3 hardware is about to enter production and the factory needs the firmware.
>>>> 
>>>> Accordingly, I suggest:
>>>> 
>>>> I have already updated the for-v3.3 branch with all the recent changes from v3.2.
>>>> 
>>>> We now (today/tomorrow) release the current v3.2 branch as tag 3.2.018, OTA release. This would be the (hopefully) last v3.2 release.
>>>> 
>>>> After release of that, we branch off master to a v3.2 branch, for historical purposes (and if we need it for anything).
>>>> 
>>>> We then merge back for-v3.3 into the master branch and start working through the usual daily builds for that to get it ready for production. I think there is still some work to do on pouring the plugins, but the core code (and in particular new modem support) should be ok now.
>>>> 
>>>> I think we will need to investigate an approach for dual builds for v3.3-or-later and pre-v3.3 hardware, to take advantage of the new ESP32 rev3 chips. I think those will require a different sdkconfig. We can do that automatically in the OTA system, by building the URL based on the ESP32 platform revision. Should we do that with the v3.3 release (even if the builds are for the moment the same), or at a later date?
>>>> 
>>>> Regards, Mark.
>>> 
>>> --
>>> Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal
>>> Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
>>> 
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at 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
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20211122/39b9cdb9/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20211122/39b9cdb9/attachment.sig>