May I suggest you stop mixing x.y beta test firmwares? There really is no good reason to keep your voluntary test community on edge about what point release version is currently available for beta testing.
Some of us will happily participate in every bleeding edge double digit dot beta test opportunity you will offer, like puppies smelling a sweat. o
Others are seeking to test whether their specific critical issue has been solved or feature change request implemented in the stable firmware release line. usually in relation to their own customer use cases.
But hardly anybody I can imagine, will have a serious and valid interest in participating in both the bleeding edge betas (v3.70~34) ĂĄnd the stable betas (v3.6x) concurrently.
Please adjust the firmware update options page to enable only to opt in for one or the other or both betas.
Thank you for your attention to this matter.
Handbags at the readyâŠ
Straight up translation please, âŠ
If you do not want to participate in the minor update testing to the current official firmware, then as long as you do not have automatic updates on it is quite easy, do not update until the next major release version testing continues. I have already got Virtual switches amd other Node-RED stiff running day to day on V3.70 so will do no further updates until V3.70 beta continues.
may I suggest having three channels in the UI with optional auto-update within the channel:
- (stable) Release, e.g. 3.65
- (hot) Fix, e.g. 3.66~1
- Beta, e.g. 3.70~âŠ
Or Release/Beta/Alpha.
Thatâs exactly the point I was trying to make. Itâs just unpractical not to be able to plan our development work on either or even both branches in parralel. Especially when, as matter of best practice, multiple instances of VenusOS are involved to allow testing before roll-out.
I guess I will need to figure out how to create a local f/w repository as a workaround. Yet another one.
As a software developer, I completely understand the reasoning of @mpvader. You can call it awkward, but it is an honest and substantiated response. Of course you may not agree with it, but please be aware that you donât need to handle the challenges of software development. You donât need to sweat when a new stable release is being rolled out to many systems. Some of the systems might be critical and even help you in real life, like, for example, a bridge closing when there is a power failure. Like always, there is more if you start to looker deeper into things.
I fail to see how that relates. Iâd be better able ĂĄnd willing to help out with beta testing multiple branches if these were available in parallel,
When you sign up as a beta tester, it seems wise to me to only install updates manually so you can intervene directly if errors occur. It also means youâll actually test the version after youâve installed it. If you allow beta releases to run automatically, your system could be significantly disrupted.
The official software releases have been thoroughly tested by larger groups on various platforms, making it safer to allow them to update automatically.
If a different branch needs to be tested, like now, you as a beta tester are free to choose whether or not to test that version. After all, you decide which beta version to install and which not to.
I would rather have put development time into quality software than in administratively handling multiple branches, which would require a software change and server changes as well. Adding a new software channel is just not trivial. It will inevitably result in all kinds of support questions as well.
It is easy to write down âdo us a new software channelâ, but it just isnât trivial. What do you pay for updates anyway? Do you have a service contract with Victron? I donât mean to be unfriendly, but the reality is that you get updates and new features like DESS basically for free.
Although continuous delivery (CD) is common practice with cloud native applications like VRM, itâs common practice to have at least two branches for embedded system in parallel.
Last official release points to a release tag on main. Main is used for next release where after internal testing a beta test might be done with the crowd.
A hotfix branch might be created from last release tag if really necessary.
I am sure Victron will not create hotfix branches just for fun.
It could be argued, if they should ship less features in a release and ship releases faster.
As I am responsible for the support of connected devices in my company (not Victron) and see the delayed response from the field, the strategy Victron follows is more than resealable.
I vote for making the three channels permanent (release, hotfix-beta, next-release-beta), where release and hotfix are the same most of the time.
This will help the crowd to decide where to help with feedback before rolling out a new release.
And yes, with the complexity and amount of different possible configurations there is no chance for 100% test coverage. We see this with our products as well.
Thx to Victron for permanently evolving your products for free!
A one-sided âpay forâ argument is without merit: Who pays us to test for Victron?
What is relevant is that participation in beta testing, without a monetary incentive either which way, depends on the quality of the tools provided.
I think you already know the answer, so just a reminder â if itâs not adding anything new, it might just come across as noise on something that has already been covered.
Sometimes trying to stay on the cutting edge can start to feel overwhelming on top of other responsibilities. Maybe itâs worth taking a step back for a bit if itâs starting to feel like alot much to keep up with.
You say what? I honestly donât get this widespread policing of the community forum. It is extremely off-putting to experience while making an honest attempt to contribute ideas and suggestions for improvements. My expectations towards a fruitful co-operation are at a bare minimum right now.
The noise as I see it, is where people stray away from the subject. Why not simply acknowledge the change request and support a community effort to create a workaround if direct implementation is not feasible.
Not sure what you are expecting, you got a direct answer? Which means your suggestion was read and considered.
The point of the beta thread is to keep it focused on issues related to the releases.
The policing usualy happens when it starts to look like the conversation is not longer constructive or is crearing noise unrelated to the origional discussion so should be its own thread.
The pont of the forum is to help with more direct answers. Not sure about you but when i am looking for information i donât want to scroll through tonnes of nonsense for the good bits. I value my time and try to do the same for others in keeping with the spirit of the forum and its intended purpose.
- Room to discuss the request on its merits
- Constructive support towards a workaround when it is clear Victron will not consider a change (at this point in time al least)
So generally speaking, and I appreciate the question: community support from and for the community to develop solutions of their own, together.
I saw that. Hence a thread dedicated to the discussion yyou want to have.
Thr beta thread was not the place.
Following the guideâŠ
yeah. I think that a troubleshooting step in the beta was to work back to an older one there. So ended up being a multiverse⊠
Yep. Hence the moderating. So the job of a beta testor is not to control the process really. But to give feedback on whether t3 beta being tested works or not and why.
The thread is a pretty heafty read these days.
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).