[NB: moved from sub-post in "BUGS" to start a new thread here - Don]
With all respect and thanks to the hard-working devs, I find it frustrating (after 5+ years using mesh) that the stable versions seem NOT to go thru Release Candidate Status first, which seems then to result in a few bugs in "stable versions" which exist for a long time as they are only fixed some random time later in Nightly Build beta releases and then months go by before the next stable release incorporting that fix..
I take my local EmComm seriously and will NEVER pick a random nightly release to operate my mesh island on. Thus when bugs like last year's out-of-the-blue issue with advertised services being auto-retired by a CRON job due to confusion with password protection on port 80 services, I have to live with it (until luckily this time I was apprised of the open-heart surgery workaround to remove that particular faulty CRON table entry).
IMO, it would be much better if more focus was placed during each "cycle" on crowd-defined "acceptance" of a RC with only bug fixes added in then until it is released as stable.version. Then Nightly Builds can go back to developing cutting-edge stuff and the rest of us can stay happy with the "current" stable release.
Thanks to all the hard-working volunteers, please accept this a humble ask and not a complaint.
- Don / AA7AU
ps: why not a 3.22.12.1 stable update to fix the DNS issue instead of referring folks to a Nightly Beta Build?
"Because of changes in the way OpenWRT names devices, this upgrade is not simple to revert without reinstalling your node as if you just took it out of the box."
Plain English please. Are you telling us to do this, or try it with just an upgrade process first? If a full reset back to NOCALL is what we have to do then please just say so. I understand that re-establishing all the settings and such will be a real pain but am eager to have the improvements.
Ed
Unlikely, IMO. This image has been tested a LOT and is pretty stable.
Orv W6BI
Ed
I and many others upgraded Rocket M2 XWs to 3.23.4.0. Mine were at 3.22.8.0. After 3.23.4.0, the radios worked fine on the mesh, but they no longer had working Ethernet ports. Had to do full power-off-reset-power-on load of 3.22.12.0 for a Loco M2 XW as a work-around.
See "Rocket ethernet port not working after 3.23.4.0 upgrade" (05/03/2023). It took three (#829, 832, 850) DRs to get what I presume is a good fix in some nightly build in mid-May.
As the software system becomes more complex (more features), I feel that it will be increasingly difficult to ensure that everything works right.
--TIm K5RA
Just for the record, since not a single dev responded to my request for dialog here, I have NOT upgraded a single node on our mesh island to 3.23.4.0 - none! Most are at 3.22.8.0 (with CRON fix) and only one has gone up to 3.22.12.0 with its ugly new web design.
I don't understand why no one here wanted to discuss using a "release candidate" approach like we used to. Really too bad. Nightly builds with lots of random new stuff may be fun and developing for the new Nerf9000 hardware even more fun, but we need it to work reliably with our current hardwre *first* before moving on to the next new set of "gee, that seems neat" features.
Sincere apologies if anyone takes offense, but that's where it stands with us here.
- Don / AA7AU (almost 6 years in the trenchs doing AREDN mesh implementation)
That's the beauty of AREDN. Unlike other types of projects that force you to buy new hardware or upgrade to the latest firmware, AREDN allows you to continue using your legacy devices with versions of firmware all the way back to 3.18.9.0. If you don't have a compelling reason to upgrade, then you can keep running the firmware you prefer on the devices you have available. No problem.
Hi, Don:
Release candidates were before my time with AREDN firmware.
So, to me, 'release candidates' is old news.
I cannot discuss it because I never used it, so I don't miss it.
What are you hoping to cause to happen by discussing 'release candidates'?
73, Chuck
I'm really glad to see the dev team revert to the "Release Candidate" approach.
My hopes are that once the tested RC becomes defined and published as the next "Stable Release" then that code base will remain unchanged except for important bug fixes, which would then be released as .1 or .2 of that code base and NOT INCLUDE ANY NEW beta development.
This way I can know that *if* 3.23.7.0 release (for example) has an issue or more, it will be get fixed in 3.23.7.1 (or .2 etc) and released as the next "stable" release with NO OTHER changing variables.
Of course Nightly builds can continue as desired with new beta stuff (and even include the upcoming NERF 9001 hardware) and eventually get the .1 and .2 fixes etc incorporated as well. Eventually that NB stream will produce the next RC and then the next Stable Release. By then, maybe I'll even have one of those fancy new NERF 9000/1 units in my fleet.
If it doesn't happen that way, "Stable Releases" will continue to be randomly defined toe-dips in the stream of consciousness dev path.
I know this dampens the "fun stuff" but I argue for the value of reliability in operation for those who aim to handle serious EmComm with AREDN networks.
Thanks for all the past work and thanks for listening to my opininated posts.
73,
- Don / AA7AU
Well, I dug and dug and dug and dug ... and I found one thing but not another:
After hours and hours of difficult research. I did find the following definition of "Release Candidate":
'A release candidate (RC), also known as gamma testing or "going silver", is a beta version with the potential to be a stable product, which is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded, and tested through one or more beta cycles with no known showstopper-class bugs. A release is called code complete when the development team agrees that no entirely new source code will be added to this release. There could still be source code changes to fix defects, changes to documentation and data files, and peripheral code for test cases or utilities. Beta testers, if privately selected, will often be credited for using the release candidate as though it were a finished product. Beta testing is conducted in a client's or customer's location and to test the software from a user's perspective.'
https://en.wikipedia.org/wiki/Software_release_life_cycle
However, when I went to look on our AREDN site for further mention of firmware titled "RC-1" or even NB 20230626 - I found nothing but a new, very cute but narrowly-constrained, firmware download page.
I guess I'm just getting out-of-phase with the development/release approach here (or just too old) ... hard to accept after a 40+ year professional career in computer software/applications/systems/consulting.
Confused,
- Don / AA7AU
I accept the way things are.
73, Chuck
If a device is in my hands, I now consult the table and if the new firmware is stable and released, I try it. If it doesn't work but not a brick I try the nightly. If it has any other notes on the lookup table I read here first to see if anyone else has used this model and what issues arise. If you look the entire firmware repository for 3.22.12.0 is linked on the right of the main AREDN page.
The only thing missing right now is an easy solution that you don't have to ask questions and can implement 100% on your own. Sure that would be nice but I'm glad I can get info and when there is an issue I can ask for a patch. The hardest part for me is that as we expand AREDN here, new people want to be told where to go and how to do it ... I can't just point them at the website and say "follow the instructions" right now. Oh well, nothing is perfect.
73, Ed
You have a team of volunteers working their tails off for the common good of Amateur Radio and the satisfaction of a job well done. These people are innovators and Geniuses in my book and deserve nothing but praise for their efforts.
As the average Joe Ham Opp all we need to do is sit back and use the product as is. Suggestions for improvement and reporting of issues is one thing criticism is step to far.
Please forgive me if I have miss understood this thread.