[BUG] 'version' is obsolete
#11628
Comments
|
As I recall, this isn't a bug, |
Thanks, didn't know that |
|
@Xeckt gave the answer |
|
How will docker-compose.yml files for versions 2.x and 3.x be distinguished without the |
I have the same question. How is this going to work...there are definitely differences between 2.x and 3.x that are not compatible with one another? |
|
The version had (and in one case still has) a very ... limited relevance. It's purpose was to ... limit what you were allowed to write in those yaml files. The only case where that's still "relevant" is for docker stack. The current file format is more of a "descendant" of the 2.x series and the 3.x series is, again, only relevant for docker stack, where 2.x had no ... relevance. I'm glad it's gone. It was tiring to see "3" as version |
|
Could the docs be updated? |
- Delete version - docker/compose#11628
Sorry to do some action on this obviously closed issue, but i have a Naive question. |
According to the docker issue 11628 (docker/compose#11628) the 'version' field in docker-compose files is outdated. It shows a warning like the following on hosts with a newer Docker version: ``` WARN[0000] /srv/plane/docker-compose.yaml: `version` is obsolete ``` Also, the specs itself state the version was only informative: https://github.com/compose-spec/compose-spec/blob/master/spec.md#version-and-name-top-level-elements > The top-level `version` property is defined by the Compose > Specification for backward compatibility. It is only informative. > Compose doesn't use version to select an exact schema to > validate the Compose file, but prefers the most recent schema > when it's implemented.
According to the docker issue 11628 (docker/compose#11628) the 'version' field in docker-compose files is outdated. It shows a warning like the following on hosts with a newer Docker version: ``` WARN[0000] /srv/plane/docker-compose.yaml: `version` is obsolete ``` Also, the specs itself state the version was only informative: https://github.com/compose-spec/compose-spec/blob/master/spec.md#version-and-name-top-level-elements > The top-level `version` property is defined by the Compose > Specification for backward compatibility. It is only informative. > Compose doesn't use version to select an exact schema to > validate the Compose file, but prefers the most recent schema > when it's implemented.
|
Love that it is gone. It was so obsolete, last week I was wondering why it is not increasing like everything in life, and now it is gone. |
- Version is no longer needed (docker/compose#11628) - The version of postgres doesn't work with the latest version of docker for some reason, puling that image results in `layers from manifest don't match image configuration`.
- Version is no longer needed (docker/compose#11628) - The version of postgres doesn't work with the latest version of docker for some reason, puling that image results in `layers from manifest don't match image configuration`.
If it's informative, shouldn't it NOT output "WARN"? I don't expect most users interpret WARN as strictly informational. |
That depends on how you interpret it. It ensures the user pays attention to it, because they might use |
|
BTW, how to hide this message? Our environment is built from multiple docker-compose files. Sometimes we have to use docker-compose commands extensively. So it may print a few screens of the warning like this: 
This is a light version of the output, actually. How to hide these annoying messages except by editing many files at once? |
yeah! remove the |
|
@bkraul The full question was about hiding without editing many files. |
|
@speller, OK what is the impediment to batch-modifying the many files? if in Windows, Notepad++ can instantly and safely (with preview) remove those lines. Or if you use a Mac, I am sure you can find a tool to use in that "glorious" ecosystem. If in Linux (or mac cli), sed is your friend...one-liner. 2 if you want to play it safe. You execute them in the root path where all your files are (even if in subdirs, I am assuming all are in For finding the files (with line number of the occurrence) that will be affected: For applying the removal of the lines with But again, sorry, I still don't see the issue here. |
|
There's a lot of files affected, changing across the various repositories requires commits, PRs, CI runs, approvals etc etc etc Here's how many public files github search thinks are affected. The number of private files is likely much larger Example code from docker's own github org still contains the version field: All of this churn and work and discussion and waste is being created... for what gain? |
|
Right if step 1 was set to warning, is step 2 not allow |
While there is a lot of files effected, it really doesn't change anything for the people who have it, it's just a simple warning to show it's obsolete so it's not actually doing anything by being there or not being there. So it's necessary to not have it, there's no major gain out of it. What is the use of it being there if it's not being used anyway? Would you rather it's there just for show? |
|
@Xeckt exactly. I see a lot of people complaining that they see a warning, and then turn around and complain that it is too much work to change the files to stop the warning. Clearly the thought process is that the tool that is deprecating this for a reason needs to just make changes to accomodate for this preference. Sorry, I know it ruffles feathers and such, but oh well. We are experiencing a massive situation with Chrome removing support for third-party cookies (specifically with Okta). We could sit and complain about "how much work will it be to re-implement to allow for this change", and try to get Google to back-track on the change, or we could actually do it, and have our applications be all the better for it. anyway, matter of preference. |
This exact argument works in reverse. If it doesn't matter, why introduce a warning at all? Everyone who sees the warning for the first time now has to wonder if it's important, look it up, read this thread, and decide whether to take action or live with the warning.
No reason has ever been presented other than "it makes things a bit tidier".
Third party cookie changes are generally about trying to improve consumer privacy. If you disagree with such changes then you should definitely voice those concerns to the vendors. Adding a warning for the presence of a field that doesn't do anything either way is not at all comparable. |
|
It should be INFO not a WARN if it doesn't affect anything. That's the basic issue here, a typo in the original PR that made an informative log line into a warning. |
Last time I checked, that "is" a reason. Might be you do not "agree" with the reason, but it was their prerogative as maintainers. Anyway. As I said, matter of preference and opinion. |
|
Yep, and you saw the resolution of that by one of the contributors...So unless I am missing something, this was not a "typo in the original PR"
|
Because people will use the version tag thinking it's actually doing something. The warning is there to show you it's not doing anything.
This is a normal process for any software involving changes and updates.
|
|
A warning is appropriate. Just like a compiler emitting a warning for an unused variable. You don't have to do anything about the unused variable, just like you don't have to do anything about the The only thing changing is that now This is a good thing! So either fix your files, using your bulk editor of choice -- including submitting a PR, going through CI, etc -- or just ignore the warning. It's doing literally nothing to hurt you. A warning is an informative message, and it doesn't matter if it's labeled "warning" or "info" or anything else. |
|
|
I would suggest that the majority of users of docker compose files were not aware of these specification changes, nor would they care. Adding this warning has effectively forced a bunch of people to learn about these subtlties. For your project perhaps this is a desirable goal? But please take some time to consider the ecosystem impact from making platform-level changes like this - especially on a project that has had an excellent backwards compatibility record for many many years.
This is great! But there is nothing about spec validation in general that requires a warning about usage of the |
Help me understand somthing here. You are saying the majority of users were not aware or do not care, but all of the sudden the particular warning behavior is deemed critical and the mantainers must pull it back? If they "don't care" as you say, why should they care about the warning, which is something someone already mentioned here. |
They never needed to care before, their docker-compose files did what they told them to without complaint.
and then one day, about 3 months ago, after docker compose automatically updated, it started emitting a warning every time they ran it oh no! a warning, I'd better go look this up and find out what was important enough to merit adding a warning, and then take the appropriate action to make sure my containers keep starting But then upon finding out what the warning is about (note that the warning itself isn't self-describing, it doesn't say what action should be taken), they find out that oh - nope. Nothing will ever break. The specification for docker-compose says that the version field is allowed but must be ignored. But we still have to either live with the warning, or change every compose file in the world. A widely used configuration file like this is an API. Changing an API has a cost. I have stated repeatedly in this thread why I believe that cost is far larger than the benefit. Every response I've seen so far has been in the vein of "well the maintainers wanted to, so you should live with it". And yes, I will live with it, and I'll change my files as I go along - but that doesn't mean I shouldn't politely voice my concerns, attempt to clearly state my reasoning, and hope that the maintainers reconsider - or at least avoid making more changes like this in future. |
Even with me being on the other side of this preference. I 100% agree with this. |
Description
After updating to version v2.25.0, the command
docker compose pull docker-compose.yamlgives the error'version' is obsoleteSteps To Reproduce
No response
Compose Version
Docker Environment
Anything else?
No response
The text was updated successfully, but these errors were encountered: