LMS-Community
Mark docker image tags of development version as such
It seems the tagging scheme of the docker images cause confusion / problems in other projects. I'd like to request to mark the tags of the development version (currently 8.4.0) docker images as such, e.g. by a "dev" or "beta" suffix.
See also https://github.com/truecharts/charts/issues/15423 where this led to an unstable version being installed by default.
But that report already quotes https://hub.docker.com/r/lmscommunity/logitechmediaserver which shows that we're doing exactly this: 8.4 is tagged dev. What is missing there?
What I think they are expecting (and how I read the report) is that they are expecting the tag to have a suffix of -dev or -beta (e.g. 8.4.0-dev).
What I think they are expecting (and how I read the report) is that they are expecting the tag to have a suffix of -dev or -beta (e.g. 8.4.0-dev).
It's not so much what "we" are expecting, it's what all automated updating tools expect by default (renovate, watchtower). The best container practice is to have versioned tags and digest-pin those with ones automatic-updater tooling.
However, if you just throw out a new version... every updater is going to see it as an update, as it has no way at-all to know it's not actually 8.4.
Please tell us what exactly we're supposed to do. We have tags by "branches" (dev vs. latest vs. stable), and tags by version number (if you want to stick with a specific version). What else is needed?
I just checked a few random, but popular packages: what we do is pretty much what nginx, redis, or Debian do. They all have version tags if you want to nail a specific version, and they have latest/stable/(some others) to tell you what you're to expect from a potentially changing version.
What you need to do is not upload beta versions on stable version tags.
Aka:
Don't put a beta in 8.4.0.
If you want version tagged beta's (which is good), use 8.4.0-beta or don't put out versioned beta's.
@terual quite literally told you that already and you can also see that none of the projects you named would put a beta in a version tag without beta/dev suffix.
Ok, fair enough. But may I still ask why this lead to confusion? Did somebody install 8.4 because they didn't know what it was? Because reading those three lines at the top of the readme was too much to ask for?
I've seen updating tools which explicitly tell the user to read the upstream changelogs/descriptions before hitting the button...
@terual quite literally told you that already and you can also see that none of the projects you named would put a beta in a version tag without beta/dev suffix.
What are you referring to?
A fix could be to add the following to buildme.pl in https://github.com/Logitech/slimserver-platforms, but I'm not sure if this would break other use cases.
$tag .= "-dev" if $releaseType eq "nightly";
Ok, fair enough. But may I still ask why this lead to confusion? Did somebody install 8.4 because they didn't know what it was? Because reading those three lines at the top of the readme was too much to ask for?
It seems that that project automatically upgrades all docker images in their repository according to some logic. What I found was that they use https://github.com/renovatebot/renovate to do this, so it wasn't a manual action to upgrade to 8.4.0.
A fix could be to add the following to buildme.pl in Logitech/slimserver-platforms, but I'm not sure if this would break other use cases.
$tag .= "-dev" if $releaseType eq "nightly";
That wouldn't be good enough as we have two types of nightly builds: stable (currently 8.3.2 - minor bug fixes only), and dev (currently 8.4.0 - under development, new features, not always stable).
A fix could be to add the following to buildme.pl in Logitech/slimserver-platforms, but I'm not sure if this would break other use cases.
$tag .= "-dev" if $releaseType eq "nightly";That wouldn't be good enough as we have two types of nightly builds:
stable(currently 8.3.2 - minor bug fixes only), anddev(currently 8.4.0 - under development, new features, not always stable).
Yeah that's confusing, def not following semver -> https://semver.org/#spec-item-11, anyways, I'll just file it on our side to use the stable tag and users won't know what version stable without checking you guys upstream manually
A fix could be to add the following to buildme.pl in Logitech/slimserver-platforms, but I'm not sure if this would break other use cases.
$tag .= "-dev" if $releaseType eq "nightly";That wouldn't be good enough as we have two types of nightly builds:
stable(currently 8.3.2 - minor bug fixes only), anddev(currently 8.4.0 - under development, new features, not always stable).
So the only option would be to insert logic based on version numbers? That would create a maintenance headache of course.
A fix could be to add the following to buildme.pl in Logitech/slimserver-platforms, but I'm not sure if this would break other use cases.
$tag .= "-dev" if $releaseType eq "nightly";That wouldn't be good enough as we have two types of nightly builds:
stable(currently 8.3.2 - minor bug fixes only), anddev(currently 8.4.0 - under development, new features, not always stable).So the only option would be to insert logic based on version numbers? That would create a maintenance headache of course.
That's the reason why we have those "anonymous" tags like dev to be independent of the actual version number. Some systems like picoreplayer fully rely on this tag, rather than the version number.
Ok, fair enough. But may I still ask why this lead to confusion? Did somebody install 8.4 because they didn't know what it was? Because reading those three lines at the top of the readme was too much to ask for?
Did you even read my explaination? It's about automation tools, not understanding this. It's also not correct semver. x.y.z is a final release, x.y.z-beta is not.
It seems that that project automatically upgrades all docker images in their repository according to some logic. What I found was that they use https://github.com/renovatebot/renovate to do this, so it wasn't a manual action to upgrade to 8.4.0.
Its not just renovate there are MANY automated updating processes being used, but renovate and watchtower are the standards at the moment in the industry. To name just two.
That wouldn't be good enough as we have two types of nightly builds:
stable(currently 8.3.2 - minor bug fixes only), anddev(currently 8.4.0 - under development, new features, not always stable).So the only option would be to insert logic based on version numbers? That would create a maintenance headache of course.
A nightly is a devbuild, thats what it means. Honest question: Do you have any software development experience at all, prior to maintaining this? Because you make a lot of very junior mistakes on even something as simple as release versioning...
Anyway: In the industry, a version WITHOUT development suffix (*-beta, *-dev etc) means "FINAL STABLE RELEASE". Fix your CI to not push dev builds on things that mean 'stable'. It's bad practice and break shit.
In the industry it's often also about how you talk to people. If you have a specific problem nobody has complained about before, and you want somebody else to look into it, then you better stay fair and don't insult people. At least in the industry I've been in so far that's best practice.
Have a nice day.
This project has a very rich history and spans more than two decades of software development and multiple name changes (testament of stability :wink:), long before SemVer even was a thing. This project is nowadays primarily run by volunteers, so you can’t reasonably expect this project to follow every shiny new development practice (not to say SemVer isn’t a good idea). The focus of this project lies with stability because a lot of users rely on this stability on a daily basis and architectural changes in the versioning scheme risk breaking a lot of existing use cases. And as is true for every open source project, if you have a problem; patches are always welcome.
What I guess is happening:
Many people nowadays run LMS in either k8s, k3s or with docker compse. With their config file managed in a local git repo, where renovate automatically merges version updates.
Or: run watchtower next to lms /
This makes running your homelab a breeze and prevents the home lab from being a 2nd job sometimes ;)
However in the case of renovate, it expects any higher full version tag (8.4.0 > 8.3.0) to be a finished release, and it'll just hard merge and problems could arrise.
What often is done, is have non 'stable' images be tagged like 8.4.0-beta for the whoe branc && 8.4.0-beta-##### for the specific build.
And that would be nice as it'll save some monitoring needs.
Then again i've never ran into issues with my watchtower setup so.. its not a big issue as far as I can tell
However, the wording on this question could use some work atleast...
Reviewing some docker best practices, I think the most logical naming of docker tags would be the following (with the current state of LMS that is):
8.3.1: released, so this should be tagged 8.3.1 and latest (and maybe stable?)
8.3.2: unreleased, so this should be named 8.3.2-nightly and nightly (or 8.3.2-beta and beta if we want to use more standardized lingo)
8.4.0: also unreleased and under development, so this should be named 8.4.0-dev and dev.
But I think the problem is that the build server does not know the status of those builds when tagging the docker builds? It only knows what the version is of the specific LMS that is being built and what the releasetype is (nightly or release). So it can only create the tags that comprise of just the version and the tag latest (i.e. releaseType == release).
But reviewing all the tags that are being built for Docker Hub I also see dev and stable, but I cannot figure out how the buildme.pl script can know how to tag those builds. Couldn't we add some variable in the buildme.pl script which provides the necessary information (which of course needs to be updated when a new major version is released)? Just like in the https://github.com/LMS-Community/lms-server-repository/blob/master/tools/updateRepository.mjs script?
Now that 8.4.0 is released it changes to this:
8.4.0: released, so this should be tagged 8.4.0 and latest (and maybe stable?)
8.4.1: unreleased, so this should be named 8.4.1-nightly and nightly (or 8.4.1-beta and beta if we want to use more standardized lingo)
8.4.1: because this is the same as the nightly this should be named 8.4.1-dev and dev.