At first sight that sounds reasonable but the reality is that it is not at all so clear where the community forum is morphing into a volunteer victron support forum. Doesn’t Victron explicitely state that this is not their support forum? Why then run it that way? Should not be at all controversial to pose that question but in my experience bringing this up is much frowned upon by part of the voluntary moderators. Basically proving the point at the same time.
Anyway, back on topic:
What are our options to roll-out v3.7 point updates, during those days that Victron is running a v3.6 beta test?
Possibly it seems to me your understanding needs some clarification.
The statement says this is not the place to as for official support. There is an proper channel for that.
Like the beta program, the community is a space where we can all share our knowlege and contribute from our experience if we want to with the view to building a knowledge base free for all. No obligation on our behalf and also no obligation from Victron staff to be involved. (The obligatory channel is the official support link).
Why are we still debating the forum? What interests me is the original technical issue and a clear workaround.
Issue:
Multiple venusOS instances in test and production. No (direct) access to latest 3.7 point release when Victron decides (on very short notice) to do a 3.6 beta. Therefore not able to plan our own roll-out schedule.
Possible workarounds:
Keep an additional venusOS instance constantly updated on latest 3.7 and make a private copy of all updates.
Put sd-cards in all other GX devices / venusOS instances, enable remote access to upload f/w of choice and do manual updates from sd-cards.
Create a private library of updates and hack venusOS to point it toward that library
A better way?
The whole point here is autonomy over our own roll-out agenda, independent of Victron’s development agenda.
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.