Direction being taken seems clear. Its on a back burner while more focus is on the 3.6
And an official statement now.
Stay with what works. Only upgrade if something does not.
Reserve testing latest betas on non critical systems.
I understand that this is, at first glance, the best way for most. But we are developing several, reasonably complicated, special customer solutions (a) that depend on 3.7 functionality, virtual devices foremost. At some point these need to be tested under operation conditions. The 3.7 branch has been halted several times already, catching us off guard not being able to do a point update while on-site with the customer. I just need to be prepared with a workaround the next time.
(a) Examples:
- A smart GPS filter based on a virtual boat tracking speed, direction, location and electric motor power settings, to filter out âimpossibleâ datapoints from the rather unreliable raw GPS datastream (think bridges while cruising the Amsterdam canals).
- A dual battery setup (DC propulsion bank and AC onboard power bank) within a single VRM instance with fully automated control over shore power charging and backup boost charging from surplus capacity in the onboard bank to the propulsion bank (a virtual reserve so to say).
For me there isnât really a debate here, the standing is quite clear.
What Iâm trying to understand from your side, based on this statementâŠ
âŠis whether the challenge is that youâve built development work around a development branch, and now the timeline doesnât align with your expectations. Victron generally doesnât publish timelines for betas, so itâs tricky to make commitments based on what might be assumed.
If this is truly for a critical system, then the recommendation in the guides is to use the official releases. By definition, a critical system should avoid surprises, while development branches can and will shift unexpectedly. As we have just experienced - an unexpected shift. I donât have all my betas on auto update so it is possible to avoid the unexpected changes.
I think thatâs also why there isnât a permanent repository for betas in the same way there is for releases â the idea is to keep betas moving forward, not to encourage long-term reliance on interim builds. (Which can also be scrapped entirely)
As MikeD mentioned, 3.7 is currently on hold while other priorities are dealt with. Even if you had kept a copy of the beta, thereâs every chance that by the time development returns to 3.7 it will have changed significantly, which could make earlier work unstable anyway.
So for now it is just be a matter of âplease waitâ â while keeping development on betas for testing purposes.
You guys are overthinking it. We are in the midst of a marine integration project, leaning heavily on the new virtual device functionality. Canât do that on 3.6 so 3.7 is critical to us. Not expecting Victron to cater to our niche wishes, didnât expect all the handbags coming out of the woods neither. Let me try one last time to refocus on the technical question: Is anybody aware of better workaround then what I suggested above?
PS, I can imagine it wonât be too long before we will go âall inâ and start cooking our own builds straight from a GitHub fork instead. Gotta keep climbing the steep learning curve to get ahead.