Build Number in Version File#432
Conversation
Added code to extract a "build number" (IF it exists) from the version file so we can compare different build numbers when the version strings are the same.
|
This PR implements a method to take into account a "build number" (if found in the version file) when the version strings between the current and downloaded files are the same. This is primarily intended for the 'develop' branch so the script can be automatically updated, but only when the "build number" is found on the 2nd line after the version string and is greater than ZERO, or greater than the previous build number. If the "build number" is not found, the functionality is the same as before. The "build number" can be any integer greater than ZERO and up to an 8-digit value. For example, at work, we use the following format for development builds, and it's the one I recommend since it is meaningful and easy to remember: YYMMDDHH = 25032522 = 2025-March-25, 10:00 PM. |
|
I'm just wondering how this will work with our GitHub workflow that uses this file for the version detection, tagging and release. Will review stuff later tonight :) |
Grab the 1st line from file.
Yes, good point. Will the following change in the YML file be enough to address those concerns? |
|
Sorry for the delay, we recently bought a new 65 Inch QD-OLED TV and have been rewatching all our fav movies on it over the last few days hahaha This is great thank you for addressing the workflow! Should we up this build number with new production releases? Remove it? Or leave it whatever it is at the time and merge it to production even though it's not a dev build anymore? I'm just curious how you picture the new workflow |
Yes it should! Thank you :) it was a side thought I had when I noticed first thing this morning it included changes to the version.txt but I figured it would be an easy solve. |
No need to apologize; I understand completely. 😉
The new "buid number" on the version file (or more appropriately, the "build timestamp" if we follow my recommendation), is really meant only for developments builds where the version string remains the same so that when users are testing the alpha/beta builds they get new updates automatically when we change the timestamp; but, if the timestamp remains the same, the updates are no longer automatic (they must do "force updates"). This allows us to control when we deem the current development branch to be "good enough" for external testing purposes. For production master releases where the version string is always updated to the next numerical sequence, the "build timestamp" is essentially ignored. IOW, it doesn't hurt if we leave the timestamp in the file when merging, but it will serve no purpose either. |
This is what I wanted to confirm with you, fantastic! But dev branch does care about the build timestamp, if the build timestamp is updated in dev, then that triggers automated updates in dev (or update notifications if auto update is disabled), otherwise we can just ignore it and people would continue to do "forceupdate" as required. We essentially only need to update it, if we expect an important update in dev more or less; for example, the little oopies I made with reformatting the webpage, I could of updated the build number then in dev, and that would of triggered all the dev users to auto-update or get an update notification. |
Correct.
Exactly. It is still up to us whether to put the "build timestamp" in the version file, and if and when it gets updated to trigger automatic updates or notifications for development builds.
Yes, those are good examples where the build timestamp would help to update users automatically, especially for those users who may not visit the SNB Forums regularly after switching to the develop branch so they may miss some important fixes or new features being added. |
|
@ExtremeFiretop, |
Goodnight buddy! Enjoy the evening! |
|
Just an FYI I noticed this when force updating my router from the existing dev version; I'm assuming last night or tonight (interactively) the script ran and downloaded the new version.txt; and just now when I tried to forceupdate; it had the build timestamp in the file but the old script still, causing this.
|
|
Once the script was updated though, now I no longer have the errors when running it. |
Ah, yes, the previous 'develop' script version must have downloaded the "new" version.txt file to do the automatic script update check, and ended up replacing the "old" version file, which was a bug that led to the error for the next check that still uses the "old" script version. Once you have the "new" script installed, the error will no longer happen. I think I should port the fix for the bug that causes the version.txt to be replaced prematurely onto the 1.3.11 version so that when the time comes for the upgrade to the final 1.4.0 release, the error does not happen. Great catch!! |
Exactly what I expierenced yes; I was downgrading my router to the stable release (alpha is causing me issues)
Agreed!
Oh you know; just doing my part; breaking things and whatnot ;) |
|
I always thought I would be a good "bug bounty hunter" |
|
Yeah, let me grab a cup of coffee and finish some other "stuff" I was doing before I port the fix over. This will become the next 1.3.12 production version to be issued at some point before the final 1.4.0 release.
Always appreciate your great skill at testing and "breaking things" LOL!!! |
Take your time!
|
Yeah, you could make some good money. There are companies that hire independent contractors to do "penetration testing" to find vulnerabilities in s/w applications, systems, or network infrastructure. |
2 participants
Added code to extract a "build number" (IF it exists) from the version file so we can compare different build numbers when the version strings are exactly the same.