Thank you for all your hard work, but I guess I will never trust your script to auto-update my network if it depends on you having reviewed the changelog instead of me.
Again the mentality is always safety first with this project and I hear out all the concerns which helps shape the path of the design choices we make.
So I'm gonna go with a triple pronged approach to this problem.
1. I'm implementing a passive changelog verification in dev as found below:
This will do a few things for us.
It will give us a little piece of mind that if someone is completely clueless and not paying any attention at all, that it will check for very obvious red flags and advise.
This will prevent users from claiming they "didn't know what they were getting into" with any given update.
The red flags phrases it will search for are:
- features are disabled
- factory default reset
- break backward compatibility
- must be manually
- strongly recommended
I've selected those phrases as I've identified a pattern in the general language used in the changelogs as found here:
https://www.asuswrt-merlin.net/node/10
and here:
https://www.asuswrt-merlin.net/node/11
If you do a
control + F search on both these pages for the phrases above, you'll find it's very specific in every case, and usually something the user should be aware of before flashing.
Why am I using whole phrases? Because I don't want to be too restrictive, the script won't care about specific words like "strongly" or "recommended" it cares about "
strongly recommended"
Finally, it will give RMerlin some passive control over this script. (if he so chooses...)
If I implement something like "strongly recommended" RMerlin may decide to actively use it as a feature if he knows it exists. Worst case is he doesn't, then it's just a passive listener in the changelogs incase he uses the same language someday. (Like he as in the past.)
2. Martinski extended the Default Delay Cycle
As documented in
PR: 86 Martinski has increased the maximum number of days to postpone new F/W updates from 30 days to 60 days. (Incase you plan to go on a month long vacation).
And he has also set the default to 15 days for new installs from 7 days.
This should give users more time in case they want to review/check change logs, or read SNB Forums posts related to the specific new F/W version.
If someone wants to review & check the change log every time before deciding whether or not to go ahead with a F/W update, they can set the delay to 30 days, which allows plenty of time for them to do what they need to before deciding to accept or stop the update.
3. Remind everyone this tool is to streamline your job, not replace it.
My personal preference as I've done already:
The rest is on the user to check the changelogs.
As always, checking SNB and the change logs will always be recommended no matter what solution is implemented.
Remind everyone to check/review the changelog, this script is made to streamline and make your job easier, you no longer need to stay up at night or do the steps manually yourself, but the research should still be done by you before-hand.
Set the delay to the maximum number of days so you can make a decision based on your comfort level.
I will never trust your script to auto-update my network
You can trust the script to update your network perfectly fine every time, what you really need is to trust yourself that you know when to stop it.
For now by default, if after 15 days, the user has not stopped the F/W update, it becomes a tacit approval to go ahead.
Remember you can simply disable it at anytime to stop any update and it's manual going forwards:
We can make it as dummy proof as possible, but at the end of the day, it's to each of you to determine your comfort level and specific network environment.
Your network is still your responsibility no matter how good the tools become. Make your own educated calls and use with discretion.
For example, I always read the changelogs and check for any changes that may affect my network setup. That's why I have set up a delay of 7 days for my own router, and 30 days for my parents & in-laws routers.
This allows me time to review & prepare for any possible changes and get a chance to disable it if something potently problematic comes up in the logs.
Keep in mind that as
@Jumpstarter mentioned above, it's very rare on it's face this would be an issue, most of the time you can upgrade merlin firmware without a concern or thought in the world.
But if somehow there is a reset needed or a feature changed, and you didn't catch it, the script didn't catch it, and the delay didn't catch it, and you still flashed and got caught off guard by a change... Well at that point it's on you and I won't even take responsibility for that, we've done all we can.
Even in a worst case were you needed to fully reset and reconfigure, as long as you have a backup as we recommend, that takes what? Minutes of time?
Compare that to how much time you'll save for every successful flash in comparison.
That was just an idea for a potential design solution. 
