You are here

development path for a Jan 2022 Stable release?

10 posts / 0 new
Last post
kj6dzb
kj6dzb's picture
development path for a Jan 2022 Stable release?
Hello Dev Team,
Im writing to inquire in regards to a stable release road map? Ive been pushing users to upgrade to Nighty builds here with in BAM / SFWEM every month. It not EZ to ask every one every month. I know that the DEV team has been busy with upgraded to mitigate the storms and UI improvements. Im hopping for comment on the path for a stable release. I hope that it could be first quarter 2022?  I would appreciate a stable release in order to stop asking users upgrade to nighty builds every month, to keep the network stable!

Long Live AREDN!
73 & Happy New Year!  
Mathison KJ6DZB
K6AH
K6AH's picture
I would stop asking them to upgrade...

Rather than wear their patience thin, I would simply stop asking them to upgrade.  The nightly builds are not to be considered for production devices anyway.  I know a lot of hams routinely test nightlies for us, but I wouldn't if you need the network to work.  Over the next couple months the risk of using a nightly will increase substantially as large rewritten modules of refactored Python code are included.

As for a production release glide path, we were hoping to wait until we had 802.11ac devices supported and a new production release of OpenWRT included.  So we are at the mercy of their schedule.  We are considering arguments for an interim release.

Having said this, we are always grateful for testing support from those who are able to do so.

Happy New Year, Mathison to you and the growing Bay area network.

Andre, K6AH.

kj6dzb
kj6dzb's picture
Arguments for a interim
Arguments for a interim release:
  1. Recent improvements made to mitigate the probability routing storms has significantly improved network stability. I would go as far as to say that the FW  3.21.4.0 & 3.20.3.1 is unstable in the light of the recent large scale test. Running 3.21.4.0 & 3.20.3.1 FW significantly increases a networks susceptibility to the out of sequence routing storms. 
  2. Recent improvements made to the pearl UI improve device stability. Resources limited devices with low memory benefit significantly.  The improvements made to the UI benefit primarily benefit slower HW. The higher preforming HW benefit from the improvements as well. The fix doesn't provide a way around the foreseeable End Of Live for 432 equipment. Its identified ARDEN FW gets chocked up on 432 equipment. It may only be a short term fix, it prolongs device compatibility, and improve the UI on all devices. An interim release should be made before additional fixes are introduced. The effect(s) of a large rewrite of the UI may introduce unforeseen problems. Prolong device compatibility with an interim release before "large rewritten modules of refactored Python code" is introduced into the nighty path. An interim release would freeze the UI code before its refactored. If no other improvements are planed or pull requests pending,    
  3. I completely agree "nightly builds are not to be considered for production devices anyway" but because the significant stability improvements afforded by running a nighty  (as of 1/2/21) not found in the 3.21.4.0. Network stability has been significantly improved here on BAM / SFWEM because of "storm" related code contributions only found in the NIGHTY FW. Resulting need is to run NIGHTY FW to maintain stability. Pushing users to upgrade ~200 devices to a Nighing build FW is unrealistic. An interim release is needed to bring the most recent advances made in AREDN out the wide spread network.
  4. Will further OpenWRT upgrades break support for 432 equipment?  
Alone I think the "routing storm" code fix would call for a STABLE release. Combine the UI improvements and the soon to come rewrite of the UI code.  The need is all the more pressing for a STABLE release.    

73 Mathison KJ6DZB

 
K6CCC
K6CCC's picture
432 equipment? 

432 equipment? 

What are you referring to as "432 equipment"?  I'm assuming 32MB, but I don't see how that translates to 432.
 
kj6dzb
kj6dzb's picture
https://openwrt.org/supported
KV3T
KV3T's picture
If we were voting (and I
If we were voting (and I fully understand that we are not), but given the recent improvements to routing storms and the UI improvements on large networks on lower power devices, in addition to the fact that a larger refactoring / UI change / language change is starting / in the works, in my mind now would be the perfect time for a stable release.  I'm not sure what the estimated timeline is for completing the UI changes, but I wouldn't think you would want to do a stable release in the middle of that effort, so I would speculate that the next good opportunity to release a stable firmware release is a good deal in the future.

I would echo that personally here at home, as well as on our small but growing network in Chicago, these nodes have been on the nightlies for testing purposes and because we have some lower resource nodes deployed at non-critical sites.  I would like to get the critical sites that are currently on the stable firmware up to include the changes discussed above, as well as get the rest of the nodes off of the nightlies while the refactoring effort is taking place.
K6AH
K6AH's picture
Thanks

Thank you all for your reasoned comments.  We will take them under advisement and let you know.

Andre, K6AH
 

K6AH
K6AH's picture
Stable Release
Last night, the project core team agreed to put out a stable release preceding the introduction of major planned/in-process code changes.  The timing for this is currently estimated at 3 weeks from now... Please remember we are an all volunteer group, so schedule slippage may occur. 

Thanks for your input to this process.

Andre, K6AH
 
nc8q
nc8q's picture
Thank you!
+1 with Jim K6CCC Thank you! Appreciate all the effort you all put into the hobby.
K6CCC
K6CCC's picture
Thank you!
Thank you!
Appreciate all the effort you all put into the hobby.
 

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer