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:


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> 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> 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

_______________________________________________
OvmsDev mailing list
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
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