Versioning scheme

[avitali 8]

Hello everybody

With the latest beta release using the stable numbering scheme, it seems Emby is nearing the release of 4.9, which is great news! However, this creates the following problem for my setup:

I'm using renovate-bot in order to pin all the tags of docker containers to a specific version. Using the latest stable release worked well with Emby after configuring renovate to disregard versions with 4 release numbers and a leading 0 as patch version.

With the latest beta release however, Emby seems to use 4.9.1 for a beta release, breaking the semver convention Emby had been following.

I'd like to get some clarification on how the new versioning scheme works, and how I can discern beta and stable releases just by using the version number.

Thank you for all the work on Emby!

[GrimReaper 4739]

4 minutes ago, avitali said:

and how I can discern beta and stable releases just by using the version number.

Nor quite sure what you're asking here, as stable 4.x (i.e. 4.8) and beta 4.y (i.e. 4.9) releases will never coexist within same 4.z branch (i.e. when 4.9 goes stable, beta will immediately start counting from 4.10.0.x). 

[Luke 42077]

Ultimately the stable release for everyone will probably be 4.9.1.x.  

[avitali 8]

Okay, thank you for the insight!

Quote

Ultimately the stable release for everyone will probably be 4.9.1.x.

I assume 4.9.1.0-beta is marking the release candidate then - and the next release will be stable 4.9.1.1? 

1 hour ago, GrimReaper said:

Nor quite sure what you're asking here, as stable 4.x (i.e. 4.8) and beta 4.y (i.e. 4.9) releases will never coexist within same 4.z branch

That makes sense. I was just confused why the beta numbering went from 4.9.0.x to 4.9.1 instead of using the previously established versioning scheme.

Is there any way to as well include the "-beta" suffix to the beta images published to Dockerhub? I'd be really grateful to be able to exclude beta releases from my renovate workflow without having to handle updates manually

[Luke 42077]

1 hour ago, avitali said:

That makes sense. I was just confused why the beta numbering went from 4.9.0.x to 4.9.1 instead of using the previously established versioning scheme.

 

Because we had to give Asustor users the 4.9 release a little early to resolve a compatibility problem with their latest software update, however we weren't ready to release to all platforms yet. So that is why everyone else will end up getting something greater than 4.9.0.x.

Don't the docker betas use dockers tagging system and have the beta tag?

[avitali 8]

15 hours ago, Luke said:

Don't the docker betas use dockers tagging system and have the beta tag?

There is a standalone 'beta' tag, however the versioned beta tags don't have the beta suffix on docker hub, i.e. 4.9.0.60-beta is published to docker hub as just 4.9.0.60

15 hours ago, Luke said:

Because we had to give Asustor users the 4.9 release a little early to resolve a compatibility problem with their latest software update, however we weren't ready to release to all platforms yet. So that is why everyone else will end up getting something greater than 4.9.0.x.

Okay, I understand! In that case it's just a one off, and I'll keep my current renovate config as is. I'd still love to see the beta suffix published to docker hub however, as it's a much more elegant solution - I just saw e.g. linuxserver.io do that for their Emby packages

[Lessaj 467]

Maybe you can utilize Github releases to determine this?

#Beta
curl -sL https://api.github.com/repos/MediaBrowser/Emby.Releases/releases | jq -r '.[] | select(.prerelease == true and .draft == false) | .tag_name' | head -n 1
4.9.1.0

#Stable
curl -sL https://api.github.com/repos/MediaBrowser/Emby.Releases/releases | jq -r '.[] | select(.prerelease == false and .draft == false) | .tag_name' | head -n 1
4.8.11.0

 

Edited May 27, 2025 by Lessaj

[avitali 8]

On 5/27/2025 at 11:51 PM, Lessaj said:

Maybe you can utilize Github releases to determine this?

Good suggestion, but I'd like to keep using renovate without having to resort to custom logic I'd have to integrate / maintain. If Emby was following proper semver conventions and / or clearly marking beta releases on all their release channels, it would help more people too I think.

I might have to switch to linuxserver images, even though I prefer to use images from the original maintainers. 

On a sidenote, I would really support this request, which could publish image-tags as is without any changes to the current CI / CD pipeline for deploying images to docker hub (excluding the work of crafting an entirely new workflow to publish images to ghcr.io of course :P)

[avitali 8]

@Lukeis there any update on the stable release of 4.9?

[Luke 42077]

1 hour ago, avitali said:

@Lukeis there any update on the stable release of 4.9?

Hi, should be very soon. We're just working through some last remaining issues on it. Thanks.

[avitali 8]

I'm quite confused now - v4.9 seems to have been released with 4.8.1.80, however there was no official blog post or acknowledgement.

However, 4.9.2.1 has now been tagged as pre-release - is this now the unstable branch for the 4.9.2.x release, or the continuation of 4.8.1.x beta? This is exactly the kind of thing proper use of semVer resolves.

@Luke is there any way you could push the beta releases with the `-beta` suffix to Dockerhub as well (same way you do it on Github)? This would resolve the issue. Fulfilling the following request would solve the issue for me too, seeing as releases are properly tagged on Github.

 

Edited October 8, 2025 by avitali

[pwhodges 2012]

4.9.1.80 is the "stable" release following the 4.9.1.36 beta. 

However, 4.9.2.1 is a beta for 4.9.2.x, but it is not the new beta stream which will follow the release of 4.9.1.80, rather a try-out specifically for the 4.9.2.x maintenance release of the stable stream.  I don't recall them doing it this way before...

Paul

[nenchiii 2]

I have exactly the same issue with renovate bot. Finally it was released new stable release for emby (4.9.1.80), so I could play with renovate bot configuration. 

So this should now ignore following tags that include following:

beta, alpha, rc, dev, test.

Did anybody already tried this?

Quote

  "packageRules": [
    {
      "matchPackageNames": ["emby/embyserver"],
      "extractVersion": "^version-(?<version>.*)$",
      "allowedVersions": "^(?!.*(beta|alpha|rc|dev|test)).*$"
    },
    {
      "matchPackageNames": ["emby/embyserver"],
      "matchUpdateTypes": ["minor", "patch", "pin", "digest"],
      "automerge": false
    },
    {
      "matchPackageNames": ["emby/embyserver"],
      "matchUpdateTypes": ["major"],
      "automerge": false
    }
  ],

[Luke 42077]

More info here: 

 

[nenchiii 2]

On 5/27/2025 at 1:27 AM, avitali said:

Hello everybody

With the latest beta release using the stable numbering scheme, it seems Emby is nearing the release of 4.9, which is great news! However, this creates the following problem for my setup:

I'm using renovate-bot in order to pin all the tags of docker containers to a specific version. Using the latest stable release worked well with Emby after configuring renovate to disregard versions with 4 release numbers and a leading 0 as patch version.

With the latest beta release however, Emby seems to use 4.9.1 for a beta release, breaking the semver convention Emby had been following.

I'd like to get some clarification on how the new versioning scheme works, and how I can discern beta and stable releases just by using the version number.

Thank you for all the work on Emby!

Not sure if you find any solution, but I have found one that works with renovate.
I had this before:

emby:
  image: emby/embyserver:latest

After I started renovate and it was changed automatically to this:

emby:
  image: emby/embyserver:latest@sha256:50284133433841756686a8da2bb3122a7e2944546d74297f12dc700a731e5e26

 

This is the part in "renovate.json" that I use now and it seems to work:

{
"matchPackageNames": ["emby/embyserver"],
"matchDatasources": ["docker"],
"versioning": "docker",
"pinDigests": true,
"automerge": false
}

I hope it helps someone who looks for same solutions.

[avitali 8]

On 11/20/2025 at 8:38 PM, nenchiii said:

 

emby:
  image: emby/embyserver:latest@sha256:50284133433841756686a8da2bb3122a7e2944546d74297f12dc700a731e5e26

 

This is the part in "renovate.json" that I use now and it seems to work:

{
"matchPackageNames": ["emby/embyserver"],
"matchDatasources": ["docker"],
"versioning": "docker",
"pinDigests": true,
"automerge": false
}

I hope it helps someone who looks for same solutions.

I guess this works, great workaround!

However I still don't get why the Emby team cannot just either stick to the convention of semVer, or just stick the same `-beta` suffix they use for GH releases on published docker images as well...

The stubbornness to not stick to best practices makes me a bit anxious in regards to what else might not be up to snuff in the codebase

[Luke 42077]

1 hour ago, avitali said:

or just stick the same `-beta` suffix they use for GH releases on published docker images as well...

 

This makes sense however that doesn't mean it can just be made on a whim. We have to look at what the impact would be to existing users. So for this reason, sometimes this sort of change might have to wait until we can bundle it with other larger changes.

[avitali 8]

On 2/4/2026 at 11:53 PM, Luke said:

This makes sense however that doesn't mean it can just be made on a whim. We have to look at what the impact would be to existing users. So for this reason, sometimes this sort of change might have to wait until we can bundle it with other larger changes.

That's great to hear! Sometimes we don't get any answer after some time and then I assume it won't happen. Thank you