Versioning scheme

[avitali 7]

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 4510]

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 41265]

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

[avitali 7]

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 41265]

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 7]

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 367]

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 by Lessaj

[avitali 7]

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 7]

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

[Luke 41265]

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 7]

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 by avitali

[pwhodges 1939]

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 0]

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 41265]

More info here: