I see you guys are at it again. This is not good practice, especially with all the recent corrupt database issues.
For those who will say that the .1 indicates a newer version, it goes by builds, which is the last four digits. So, build 6241 may be from a different branch, but it is three commits behind 6244. This may or may not lead to issues for those already running 6244.
Add there has been no release notes for the past two - three beta builds so itâs unconfirmed what was actually fixed in those builds.
But I suspect itâs related to Windows server bugs based on some forum posts Iâve read. Still, lapse in procedures âŠ
Says who?
I donât think this needs alarm. Build numbers may not correlate with code changes, and as mentioned, code may be changed in different branches.
Precisely.
Sure, but no release notes is just bad practices which keeps happening every few months âŠ
Do you mean the last few betas that appeared in-app before they got a forum thread post? One of them wasnât even on the download page immediately - that was odd.
I think at least one of those updates did get a new bullet in the in-app release notes, but I wouldnât swear to it.
I mean I agree completely. Detailed release notes are HUGELY appreciated. Plex is usually one of the best about actual release notes. It made their absence even more obvious.
âBug fixes and feature improvementsâ, gah, so many apps.
I posted this as an FYI more than an alarm. The same thing has happened several times with various client releases, always a mix of beta and stable. In the case of the Shield, at least, this has led to omissions of fixes in other development branches when they finally got merged.
Are you going back and forth between beta and public?
I can give no comment about beta changes being merged into public. 
Never back, always âforwardâ, which can sometimes be deceiving.
How so?
Genuinely curious. Are you going to the most-recently-released version, whether itâs public or beta?
Like I said above, lower builds in newer releases. I understand Plex wonât comment 
Always, but when I notice something like today (last week I caught it too late), I hold off.
And for those curious, last week (or the week before, I forget) a release got pulled after I had already installed it, and that release also had a lower build number after a newer point release. This was later rectified with a proper and newer build release.
And Chuck just proved my point by creating this thread PMS 1.29.1 HW Tonemapping Testing, Questions , and Answers
Clearly, as of right now, 1.29.1. is a separate development branch that started a while ago, and in parallel with 1.29.0. Iâd prefer if branches like that, where more testing and feedback is required, were released separately from the regular beta branch, and would not prompt an update from within PMS.
I guess I donât understand your concern exactly.
In semantic versioning the 4th position is usually considered âopaqueâ. I donât assume version 1.1.1.10 is newer than 1.1.2.2, because the significant positions are larger. They might have done more respins of 1.1.1 than 1.1.2. I think itâs a trap to assume there is meaning in the 4th position.
Thatâs what I expect from beta releases - thatâs where any churn is. Features, fixes, changes.
I donât think of beta as VIP or as âstable but earlyâ.
They do make âexperimentalâ forum builds available sometimes, but those are usually also KNOWN to break things, or are incomplete.
I donât mean to be arguing with you, Iâm trying to understand your perspective.
Your example doesnât use build numbers at the end. I realize those are mostly omitted in public software releases, but developers still work with them internally. My point, and Iâve made it before in other threads, is that a stable release should always have a higher build number than the beta it follows. A beta release newer than the current stable should also have a higher build number, unless it is from a different branch currently in development and asking for specific feedback, like today. Plex have handled this well in the past, but not always consistently. Iâd like for the update notification, stable or beta, to only get triggered when a higher build is released publicly. Hope that makes sense.
Oh, and while I always update to the latest available, I donât install experimental or testing branch builds offered here.
Just felt the hair on my neck stand up.
What did I do now?
LOL nothing at all, Chuck 
I used 4 positions on purpose. Why donât you think my examples are build numbers? The 4th position isnât necessarily âbuildâ in my example ⊠or in Plexâs.
The 4th position doesnât imply âbuildâ, itâs âinternalâ.
âBuildâ doesnât imply code changes anyway, it might mean somebody changed a test script, it might mean somebody hit Compile again, etc.
But more importantly, it doesnât make sense to compare âbuildâ numbers across branches. Thereâs often more work done on a âfutureâ branch, but sometimes there will be more activity on a âstableâ branch. It could be as simple as an intern editing release notes multiple times!
(And to be clear, I donât know what Plex does internally. I just donât read anything into the fourth position.)
Letâs just blame Chuck.
To me, an increase in build number means an added commit.
