[Ovmsdev] Changing Existing Functionalities

[Mark Webb-Johnson]

One possible convention for this is to:

Identify the car version early on (either automatically, or by configuration) and store it in a local member variable. Perhaps as an enumerated type.

For new experimental features, key them on either (a) specific car version known to work, or (b) a configuration option being enabled for that feature.

The above would allow new features to be released for vehicle versions they have been tested on, maintain stability for other vehicle versions, but also allowing other types to set a config variable to be able to test the feature (and later enable it by default for that version should it be found to work).

Regards, Mark.

> On 14 Dec 2020, at 1:22 PM, Derek Caudwell <d.caudwell at gmail.com> wrote:
> 
> I envisage following a robust testing process outside of the main repo being a bit more difficult with the Leaf because of the quite substantial changes in the can bus framework/messages over the years. A change that works for more recent years but not for prior years is not always easy to spot, also improvements/additions of metrics may only work on a particular year unless another dev with a prior year implements and tests them. 
> 
> Without a group of Leaf devs or testers across the various years that can be called upon to test prior to putting through a PR to main I expect future changes will stay in Leaf devs repos untested for other MYs, as there is no particular reason for others to jump in and test the code to confirm compatibility. 
> 
> PR487 will be a good test case to see if the approach proposed can work in practice. 
> 
> 
> _______________________________________________
> 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/20201214/400fc06d/attachment.htm>