But I'm afraid I won't get all my settings back and that I don't really like a sole LUCI interface
So, I understand that I can upgrade to this:
GL 4.7.0 Beta 2024-10-18 Download for Common Upgrade and Uboot (but I'm not sure the OpenWRT is more up to date that the 4.6.8 version (2024-10-17);
GL 4.6.6-op24 Release Candidate 2024-10-14 Download for Common Upgrade and Uboot : but I'm not sure all new functionnality bought by 4.7 is in there...
Can you confirm the the GL 4.6.6-op24 will get the updates that came for the upcoming 4.7 version?
Do this GL 4.6.6-op24 version contains all cve fixes included with 4.6.8? Or 4.7 ?
I know that I should erase setting when upgrading. I did backed up the settings from the 4.6.8 version inside LUCI.
Should I add something else to the backup in order to get exactly what I have now in case I want to downgrade to 4.6.8?
No, I can't confirm it since I am not into development. Maybe @bruce can.
The backup file from luci should be enough. Keep in mind that all 3rd party applications will be lost anyway. You might need to backup your opkg packages then: HOW-TO: Script: List My OPKGs (to a file for backup)
From what I read, openwrt 24 still isn't ready for release. I think changing from OPKG to APK has something to do with the delay. They've complete migrating to kernel 6.6
Actually... alot of the main stream openwrt has been improved but it is time consuming to pick the correct time, and then there are probably also other certain hardware which may show undiscoverable issues within the wifi driver though these issues are likely closed in to a small group of devices.
Only issue currently with master is how dnsmasq.d works, this is currently sorta broken which then breaks logic for nextdns and other things because packages have no clue where to find dnsmasq.d since they added support for multiple dnsmasq instances not just dnsmasq servers.
^ still i find it weird why someone want multiple dnsmasq processes and then uses a uci'd random name for dnsmasq.d like dnsmasq.d.cfg28382 which goes against its purpose for overriding global things to all servers, i yet have to discover such type of use case / setup , there is a discussion to revert this change, i'd agree with Stangri here but i also think multiple instances should be supported aslong it doesn't break dnsmasq.d which it does currently
For apk i would not worry too much for this since they seem to choose the path of having both opkg and apk.