[Ovmsdev] Moving to a production cycle

[Michael Balzer]

Am 21.02.2018 um 03:05 schrieb Mark Webb-Johnson:
> On the firmware side, we need to move to a production style release cycle, and I will need to provide the first ‘factory’ firmware around the second week of
> March. Accordingly, I’m setting up some clean build environments and OTA release repositories (so I can cleanly build v3.0 and v3.1 firmware and have it
> available for OTA download).
>
> I have created a changes.txt log file in the root of the project. I would appreciate it if those with commit access to master could update that file when they
> merge/commit changes to the project. The top of the file will contain an entry for the ‘next’ version, so the change text just needs to be added below that.
> When the version is ready to go, I will update changes.txt with the date and name, commit it, tag it, and then build OTA versions for release. Please only use
> tags for OTA versions - or just don’t tag at all for the moment and let me maintain this.

OK. How about using separate branches for release and development. That way we can cherry-pick important fixes early into the release branch if necessary.

> The last list of things I have for this build are:
>
>  1. OTA via HTTP. SD CARD firmware updates seems to work fine today, as does serial flashing. I’ve still got to make the changes to HTTP firmware updates to
>     use mongoose and support the new ESP IDF v2.1+ firmware arrangement of putting the checksum at the end of the firmware file.
>
>  2. We need some simple high-level configs for auto-starting things. Stuff like vehicle type, whether the v2 server should auto-run, etc. Make it simpler for
>     people to configure, without having to use scripts. This can be mapped to v2 protocol parameters/features.
>

Config for vehicle type is there (added that for the web UI), but I haven't done the auto start on this.

With automatic start of the vehicle module, wifi, modem & server connections, I think we need a rescue scheme. I.e. if the boot crashes, the reboot should
automatically be done without any auto start -- otherwise the only option to get back to a working module would be to erase the config. I'll have a look at that.

Btw, how about activating wifi AP mode as the factory default, i.e. with SSID "OVMS" and password derived from the MAC or ICCID? That way a new user can power
the module on and directly connect to the OVMS AP and do the initial configuration with his/her browser.

Regards,
Michael


> 1.
>
>
>
>  2. SPI RAM support and stability for v3.1 hardware (as well as compatibility with v3.0 hardware).
>
>  3. Finalise the partition sizes. I think we can squeeze a bit more (maybe 3x 5MB firmwares, plus 512KB store?).
>
>  4. End-User Documentation.
>
>  5. Real-world stability (in cars).
>
>
> My concern is to have a relatively stable firmware that is usable for technically capable end-users in their cars, but also to have a way for them to simply
> update the firmware to keep pace with the fast release cycle we expect (at least in the coming months).
>
> Anything I’ve missed?
>
> Regards, Mark.

-- 
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.teslaclub.hk/pipermail/ovmsdev/attachments/20180221/219658bc/attachment.html>