What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

MerlinAU MerlinAU v1.3.11 - The Ultimate Firmware Auto-Updater (GNUTON SUPPORT!)

All we would need to do is increment the version with each new PR, but that's generally not how we handle versioning 😁

All of these PRs are in the dev branch and all these changes are still under the "version 1.4.0" until released.
I was not thinking incrementing version by PR 😵‍💫, but rather recognizing "hot fixes" as some of the other add-ons do. I was just thinking that it might make debugging easier for you since more users would be on latest (or nearly latest) version within development branch. Possibly include latest PR number in release to key off?
 
I was not thinking incrementing version by PR 😵‍💫, but rather recognizing "hot fixes" as some of the other add-ons do. I was just thinking that it might make debugging easier for you since more users would be on latest (or nearly latest) version within development branch. Possibly include latest PR number in release to key off?
Or, "simply" executing forceupdate code (when cron job fires) if on develop branch and auto script update enabled.
 
I was not thinking incrementing version by PR 😵‍💫, but rather recognizing "hot fixes" as some of the other add-ons do. I was just thinking that it might make debugging easier for you since more users would be on latest (or nearly latest) version within development branch. Possibly include latest PR number in release to key off?

Yeah that's why I mentioned it's not generally how we do the versioning, it would work with the current implementation, but it wouldn't be ideal.

Your mentioned ideas has sparked some thoughts. I'll discuss with Martinski, but generally the understanding is that dev is an active development branch and stuff can change quickly and without mention.

It's the fun apart of being on the development branch with us. 😉

I realize you have an army of routers, but you only probably need to test the dev branch with one or two I would think, the rest could stay on the production branch?
 
Yeah that's why I mentioned it's not generally how we do the versioning, it would work with the current implementation, but it wouldn't be ideal.

Your mentioned ideas has sparked some thoughts. I'll discuss with Martinski, but generally the understanding is that dev is an active development branch and stuff can change quickly and without mention.

It's the fun apart of being on the development branch with us. 😉

I realize you have an army of routers, but you only probably need to test the dev branch with one or two I would think, the rest could stay on the production branch?
Correct, but it is initially tested when you post it to dev branch. I generally update nodes all together as development progresses, but that's just me...
 
Correct, but it is initially tested when you post it to dev branch. I generally update nodes all together as development progresses, but that's just me...

Fair point I'm not trying to change your workflow, just a comment on how we usually work in the branch. You are correct that all PRs are tested before going to dev, this was just a small oversight due to having to reformat last minute.

It brings up a thought which is if you happen to not update to the dev branch right now, and decide to remain on production (maybe due to not liking the dynamic nature of the dev branch), you would be missing some recent fixes we found while troubleshooting.

Maybe of value to consider backporting those fixes to production? Although I feel we are near the end of beta testing at this point, I would say I'm mostly waiting for a new firmware drop so people can report their successes or potential bugs they find.
 
MerlinAU 1.3.11 Released!

What's Changed/Fixed?:

As previously mentioned above, Martinski and I have decided that 3 fixes from beta version 1.4.0 should be back ported to production.

Backport 1.4.0 Fixes to 1.3.11 Production
This includes changes from the following PRs:

PR: [ #415] - Improvements & Enhancements
  • Increased sleep time to 15 seconds after removing 3rd-party cron jobs to allow already started cron jobs to complete execution. Most cron jobs finish in a couple of seconds, but a few may require more time, especially those dealing with background SQL database operations (e.g. uiDivStats, connmon, spdmerlin, ntpmerlin, vnStats) so allowing more time can prevent corrupting the database/CSV files if the operation is abruptly interrupted.
  • Added commands just before removing/unmounting the USB drives to make sure that any existing I/O blocks currently buffered/cached are flushed and written out safely to the USB drives.
  • (Thanks @Martinski4GitHub @Martinski)

    1742885532684.png
    1742885333771.png

PR: [ #423] - Minor Fixes
  • Fixed a rare and uncommon "post email upgrade" bug we found back in January.
  • Added a check to validate the downloaded firmware version by MerlinAU is in fact the version found by the router's webs_update.sh script. (Essentially blocking accidential downgrades if a firmware is issued and recalled)

    1742885358010.png

PR: [ #424] - Typo Correction
  • Fixed a long standing bug with the firmware decompression validation step, which allowed the script to continue even if the firmware unzip process failed for some reason.

    1742885446996.png

Thanks!
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Back
Top