Lower build numbers in newer releases (NERD ALERT)

Plex Media Server
21
  1. PMS 1.29.0
PMS 1.29.0.6244-819d3678c  - September 22, 2022

is PMS 1.29.0 release tag, packaging build 6244

  1. PMS 1.29.1
PMS 1.29.1.6241-d3d56053f - September 22, 2022

is PMS 1.29.1 release tag, packaging build 6241.

To clarify what’s happening here.

  1. If there is a hotfix needed for any version
  2. And that version results in a new binary package
  3. The build system will assign it a new packaging/build number

These numbers are sequential.

What you see here with 1.29.0 and 1.29.1

  1. PMS 1.29.1 was built , tested, and released. (I’ve had 1.29.1.6122 for a few weeks)
  2. PMS 1.29.0 had a hot fix applied , tested, and now released

TO BE CLEAR:

These are all on the same “branch”.

We have the ability to go back and “hotfix” anything which is “beta”

22

Understood, but the concern here is, has that same hotfix applied to 1.29.0 also been applied to 1.29.1, being a newer release. Possibly not, because it’s a different branch and not everything might have been merged yet. So, if I’m running 1.29.0. and I need that hotfix, I’ll get prompted to now install 1.29.1, which doesn’t have it (hypothetically).

1 Like
23

Yes it has been applied.

I can look in and see what got applied to what.

It’s very common for us to fix "Current’ first.
Next, we start working backwards as far as needed.

What you aren’t seeing is:

  1. Developer’s sandbox gets the fix.
  2. Developer tests
  3. Alpha tests
  4. QA test
  5. Changes applied to current (in process) release candidate
  6. Developer steps to previous release
  7. Applies changes again as needed.
  8. Another build (or two or three to test)
  9. QA test
  10. and out it all comes
2 Likes
24

So, I’m going mostly by my experience with the SHIELD client, where this exact thing has happened several times this year alone. Fixes that had been in previous stable releases were not merged into the following betas and subsequently also not into newer stables. That was a problem for a lot of us.

25

I cannot speak to the shield.
I’m here in Windows only because I was called out

I can reach out to the development team and ask.

Can you give specific instances?

26

Has all been fixed since, it just took a very long time and several bumps. All good on the client side right now. And I appreciate the insight, Chuck. I’m just OCD about build numbers not increasing consistently :stuck_out_tongue:

1 Like
27

Then it’s DARN GOOD you don’t look at the belt I wear with my pants!!!

:stuck_out_tongue:

3 Likes
28

Kinda. Its the lack of server side release notes and/or late posting of them. If you look at the announcement page you will see they go from Plex Media Server 1.29.0.6219 to Plex Media Server 1.29.0.6244.

  1. There is no details on what was in Plex Media Server 1.29.0.6244 as none are posted for that build when it went out to beta. Its now available to everyone.
  2. The release notes for Plex Media Server 1.29.0.6219 where posted days after the build was actually pushed out after it was discussed on another thread.

That’s really my comment. Its a lapse from the team and it happens every few months.

1 Like
29

I think that’s the wrong thing to be worried about - those numbers don’t imply what you’re thinking they imply.

The devs just messed up and didn’t backport the same fixes to the other branch.

I dunno how, but I’m sure it was Chuck’s fault.

30

:cry:

runs away in shame

1 Like
31

Oh for sure about the worrying, but I stand by my view on build numbers/commits :wink:

32

The ‘build number’ is just the job number as it ran through the CI system.

There’s no other significance to it.

The commits applied have no bearing on it.

The build system uses a tag . That tag is what gets or doesn’t get commits.

33

I mean, you can stand on your head if you want. :slight_smile:

Say they are working on a newer, beta branch, and they create a build from that branch.

Then they do a build from a public/release branch.

Depending on how their system works, the chronologically-later build MAY get a larger number. Even though it’s from a different branch.

It doesn’t imply that either has “better” code.

(It might not work that way, because those numbers don’t have public meaning. But it also might.)
(Edit: Yeah, what Chuck said.)

34

Yes, that’s mostly where I’m coming from with the builds, commits, and branches. I get that you guys have your own system, but it makes sense in general.

35

But like I said earlier, in this case I shouldn’t get prompted to replace my “newer” branch.

36

Did this happen?

The Plex updater offers the “biggest” version from the train you’ve selected, considering all parts of the version string.

37

I think we’re going around in circles now. Chuck cleared it up, for the most part, and I thank everyone participating here :wink:

38

Yeah, to be clear, build numbers are simply chronological. If we re-run a build of the same commit, it’ll have a new build number. The commit ID is the hex portion after the build number (and is mostly meaningless to anybody without access to the codebase). If we do a new build off an existing release branch (e.g. to backport a fix), it’ll have a newer build number; this is pretty routine and entirely in-line with PMS release procedure, and I don’t have any plans to change that.

2 Likes
39

Maybe this exists but is there an ignore function for updates ?

Not a big deal to ignore the update notification but could a switch be employed to ignore update offered ?

40

I mean, I don’t let PMS update itself anyway. I always do it manually, but sometimes it so happens that something gets released and later pulled, with no notes to go by.

I should have put NERD ALERT in the thread title :rofl: