Skip to content

[Bug]: Inconsistent docker versions #97

Description

@hadmut

Is this a critical security issue?

  • This is not a security issue.

Describe the Bug

Hi,

I'm currently (just now) getting:

REPOSITORY                            TAG                   IMAGE ID      CREATED       SIZE
ghcr.io/openvoxproject/openvoxserver  latest                1036bc79ea69  9 days ago    783 MB
ghcr.io/openvoxproject/openvoxserver  8                     1036bc79ea69  9 days ago    783 MB
ghcr.io/openvoxproject/openvoxserver  8-latest              47de188c9ddc  5 months ago  838 MB


Why is :latest and :8 fresh, but :8-latest 5 months old?

Problem with build/tagging process?

Expected Behavior

8-latest should not be older than 8 and latest.

Steps to Reproduce

Pull them all

Environment

Ubuntu 25.10, podman

Additional Context

No response

Relevant log output

Activity

  1. davidassigbi commented on Nov 30, 2025

    @davidassigbi

    There also seem to be some some inconsistencies in the readme as well.
    The docs mention this (<openvox.major>.<openvox.minor>.<openvox.patch>-v<container.major>.<container.minor>.<container.patch>) is the version scheme however since the 8.8.1. the container versions look sth like <openvox.major>.<openvox.minor>.<openvox.patch>-<branch-name>.

  2. hadmut commented on Nov 30, 2025

    @hadmut
    Author

    What is the difference between :8 and :8-latest?

    Should *latest always point to a stable version, while :8 should point to the latest 8.x, even if unstable/development?

  3. davidassigbi commented on Nov 30, 2025

    @davidassigbi

    *-latest should definitely be the actual latest, whether it be stable or not, maybe not even functional.

  4. davidassigbi commented on Nov 30, 2025

    @davidassigbi

    The tag scheme mentionned in the docs is very informative. A tag like 8.8.1-v1.0.0 gives plenty of useful info. I think they should just stick to that to make it easy for users...

    Adding versions like 8.8.1-stable, might also be nice.

  5. hadmut commented on Nov 30, 2025

    @hadmut
    Author

    Packing too much information in the version label makes it unusable, because

    • you have to update configs like Dockerfile too often
    • you end up with hundreds or thousands orphaned images
    • it is a security problem, because if a patched version get's a new label, automatic updates won't work and people will not always update their versions.

    Packing information into labels makes sense only if you want to keep things in parallel. Otherwise, it is much better to put things like container versions or patch levels in annotations.

    And no, *-latest should not point to the latest, even if non-functional, but to the latest usable and recommended, because that's what users are going to use.

    Labeling alpha, development oder even non-functional versions als *-latest breaks productive systems and makes everything unreliable.

    That's what the pure version numbers or *-unstable is for.

  6. rwaffen commented on Dec 5, 2025

    @rwaffen
    Member

    8-latest is something a came up with to have it not be called 8-main. because i do the <release_version>-<github_ref> tags for when you do a tag. but yes, this is all a bit confusing, i understand. i'm not satisfied with this myself. have to come up with a better pattern. 🤔

    maybe simplify this to only do:

    • 8
    • 8.x.y
    • latest

    we thought we might need 8.x.y-vx.y.z to have fixed container versions, because often we work on the container build up, but the software version changes not so often.

  7. rwaffen commented on Jun 23, 2026

    @rwaffen
    Member

    It should be fixed with #131 . If not, feel free to reopen/rebase or open a new issue/pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions