[Docker Compose] V1 End of Life Policy #257
Comments
stephanierifai
added
community_new
stephanierifai
changed the title
|
proposed notice on project's github: docker/compose#8589 |
|
My first response is that this is way too fast, especially since docker-compose v2 is not even yet available for Linux, nor even thought through how it will be available. I think stopping all but security fixes is one thing, but security and basic maintenance probably needs to be a year after v2 becomes available on Linux. And that, of course, depends on how it's made available. |
Not yet "as a system package" (work in progress), but definitively available. This is just a question of running a |
|
Just saying... as a highly motivated user (I need it for ddev tests on Linux) I've been following all the issues on docker-compose v2. And even I haven't yet discovered how you do it, with or without packaging. I was delighted to see https://github.com/docker/compose-switch come out... but it still has no instructions in the readme. When there's a standard, documented way to use and maintain/upgrade docker-compose v2 on Linux (not I do think there's some crosstalk about the availability of the |
|
There's no "docker-compose v2 on Linux". Compose V2 is About Linux availability, we indeed don't yet offer those components as system packages. Doesn't mean Linux users can't install Compose v2 and compose-switch. We miss documentation for sure, but this is just a question of days to get this available. |
|
I think there may just be a whole bunch of bundled things going on here, and it's going to be important to sort them all out.
There are loads of implications here:
I should note that "running curl commands" is not a generally accepted practice for managed Linux machines, so it will be important to get these tools packaged fully as soon as possible. I think I won't be the only one confused by the decision to do away with docker-compose. It's an old friend with a thousand uses and continuing it as a wrapper on compose v2 would be so terribly easy. |
|
Based on feedback we have decided to focus our efforts on making the experience better for Linux users, this is has been edited above. For history, the previous proposal was: 🔏 As of September 28th, 2021 new features and bug fixes will only be considered in the V2 codebase. Users will be defaulted into Docker Compose V2 and it will be considered GA. Users can still opt out through the UI and the cli. Docker Compose V1 will only be maintained regarding security issues. |
|
For how long will users be able to switch back to using docker-compose (v1)? |
|
Very glad a Would be nice if A little nervous about the push to V2 when there's still some open issues like docker/compose#8505 preventing me from using it fully but hopefully all resolved soon. Also, |
|
Thank you very much for the new release! |
|
Hi @jpic ! Thanks for your feedback :) Do you mind sharing what version you are on 🤔 It should be available in V2 https://docs.docker.com/engine/reference/commandline/compose_convert/, but happy to look into it further. |
|
Hi @stephanierifai, The new convert command as implemented in v2 serves a completely different purpose, which is now to "output information duplicated from docker inspect for debugging" (according to this comment), in v1 it used to "output a usable stack configuration", which you could use to spawn new stacks. The documentation states:
While it does that, it previously did it so that you could reuse the output to spawn a new stack, and it's not possible anymore with the new output, as documented in issue docker/compose#8914. It also used to generate a more readable format, which it doesn't anymore because it now "expands short-notation into fully defined Compose model", I'm not sure if that's a feature anymore or rather a side effect caused by the current implementation in v2. The other problem concerning the migration, is that it's not clear whether we should reimplement this feature from v1 on our own, or if compose is going to fix it in further versions ... A clear statement would help a lot! |
|
That's both a side effect (go being a typed language, Also, |
I'm sorry, does it still output hardcoded full network names with the project name prefix ? |
|
It indeed resolves resource names as they will be created, so you can't use to run a distinct stack. The output is a fully usable configuration, but not a configuration you can tweak for another project |
|
If my compose defines a network "foo", then running convert should output it as "foo", not as "directoryname_foo", that's actually modifying the data I'm feeding into convert, it's not the same feature. It should not be named convert. Call that "inspect" if you want, and then decide if you're going to port the convert feature from v1 to v2 or drop it. |
|
the command name as documented by the command line is Whatever the command name is, replicating compose-v1 |
It is a mistake to use the same name for a commands that is not compatible, even more "for compatibility". That causes more migration problems than if the alias just wasn't there at all! It's confusing... Implementing config in go is possible with a library (mergo) that one of your libraries is using, you could also use a template! Or even do a pass on the data prior to outputting so that the network and volume names you feed into it don't change... Anyway, it'll have to be more than a one liner that is basically the current implementation, but we already have 3 solutions right there. If you're committing to dropping the feature it's fine, just document it, that's what I'm saying, and we'll maintain it in the python version, because in the mean time it's not clear how we should deal with this. |
|
mergo used in compose-go merges go structs after the individual yaml files have been parsed. About resources prefix, if this is the only blocker, I guess we could look into being able to not append those in compose-go, so that |
|
Can't you first merge at the YAML generic model level ("dict" or map level), instead of the unmarshalled Go struct level? Wouldn't that keep merging compatibility with v1 behavior? |
|
Prefixes are one completely unexpected breakage for sure, but the expansion
of volumes just seems completely useless.
Feeding:
```
volumes:
- ./syncthing:/var/syncthing
- ./data/media:/app/media
- ./spooler:/spooler
- ./log:/app/log
```
You get:
```
volumes:
- bind:
create_host_path: true
source: ./log
target: /app/log
type: bind
- bind:
create_host_path: true
source: ./data/media
target: /app/media
type: bind
- bind:
create_host_path: true
source: ./spooler
target: /spooler
type: bind
- target: /tmp
type: volume
volume: {}
- bind:
create_host_path: true
source: ./syncthing
target: /var/syncthing
type: bind
```
Add random flags to do half of the job if you want, but again I'm not requesting
anything, I was just reporting bugs in this new implementation as I naively
thought it was just a matter of time before they were fixed, this won't happen ok,
I'm fine implementing my own in Python, I'm just now saying this should be
documented to help users transitioning from v1 to v2 because the situation with
this command is extremely confusing.
It's a mistake to keep the name of the command because this confuses users
into thinking that compose v2 is going to try to reimplement it, instead of working
around what seems like a broken implementation is fixed they should be re
implementing on their own. It's a big difference when you know if your fixes are
going to be temporary or permanent.
|
|
@jpic resource prefix incompatibility has been fixed Could we please stop focussing on tiny implementation details for a specific sub-command that is just a topic for an issue, while we are discussing here the global strategy for Compose V1 End of Life? |
|
Nice! Thank you for fixing the prefix! Volume expansion is absolutely pointless in the example I've given because the content of the bloat lines is exactly the same for every volume, plus there's a new default tmp volume that your config is adding, it will stay as-is even when the upstream default changes, but I understand it's not easy to spot in the bloat. I'm just backing my suggestion with concrete examples but I'm actually talking about the strategy for v1 EOL: I think documentation should state that the config command has been dropped and that a new similar command may be used instead so at least users don't naively believe that a port of the command is in progress. If it's not going to be the same it should not have the same name because it's confusing. It's a common practice to document the BC breaks when releasing new versions, I think compose should also be doing that, like any other software... Because it helps transitioning. |
|
none of the commands are strictly identical to the v1 one. Event |
Nope, the behavior with single quotes around the value in docker compose V1 is platform-dependent:
If anything changes with respect to quotes or other escape character processing when reading .env files in compose V2, then this needs to be announced loudly (and correctly) in the migration docs. https://github.com/compose-spec/compose-spec/blob/master/spec.md sounds like the behavior of compose V2 matches V1 on Linux. That would be great! |
|
I just noticed the April 2023 date on
I think this needs pushed out a while because compose V2 as released does not work for building large compose projects @ndeloof just put in a fix docker/compose#9091 that if I am reading correctly is tagged for 2.15.0 and according to the documentation https://docs.docker.com/compose/install/ for windows we need to wait for Docker Desktop to incorporate the change. Given what seems to be a monthly release cycle, we may be able to get it by late Jan. and time to get it into our build environments it is likely mid Feb. leaving only a month and a half to actually verify the fix works before there is no way to disable V2 on windows. (Linux simlink's don't generally work well in windows). Also the default buildkit builder in Docker desktop is not configurable moby/buildkit#2906 making the issues with parallel builds worse. Our system setup is to install docker and disable compose v2 and given the number of issues you find on the web/github related to parallel builds where the solution provided is not possible in windows (due to the above issues). I propose extending the date out 3-6 months and possibly adding a notice inside the Desktop GUI that V1 will be removed in an upcoming release. To encourage those of us with large systems to give compose V2 another try, as we have been burned for a while. like the comment here docker/compose#9091 (comment) from @WolfspiritM
|
|
Due to MAC + VPN + DNS issues in Go prior to 1.20 our user base is required to use docker-compose v1 in order to use the Python dns resolution paths instead of the Go based ones. Removing the ability to opt out of v2 should be gated by getting a release of Docker Desktop that is built with Go 1.20 or later. |
|
@draco2003 latest Docker Compose v2.16.0 release is built with Go 1.20, see changelog |
|
I can confirm v2.16.0 resolves the MAC + DNS + VPN issue! 🍾 |
Addresses docker/roadmap#257
Compose V1 has been end-of-life'd docker/roadmap#257 Compose V2 is a Docker CLI plugin and installed a bit differently.
|
@stephanierifai I believe that we can close this issue |
|
@hyu please close this issue as completed |
|
This issue is now closed, as Docker Compose v1 has been deprecated as of July 2023. More details in our docs page, "Migrate to Compose V2". |
Tell us about your request
End maintenance of Docker Compose v1
Which service(s) is this request for?
Dev-tools
Tell us about the problem you're trying to solve. What are you trying to do, and why is it hard?
The goal of compose v2 was to align on Go for most of our development. In order to focus our time towards new features and enhancements, we need to make v2 the default and phase out v1.
Are you currently working around the issue?
N/A
Additional context
On April 26, 2022, we announced the GA of Docker Compose V2. We want you to have ample time to transition to Compose V2. We won’t sunset Docker Compose V1 immediately, and developers can still revert to V1. Given the numerous successful transitions to Compose V2 so far, we’ve created the following proposed timeline for Docker Compose V1's end of life (EOL):
October 2022 - 6 Months Post GA
docker-composetodocker composedocker-compose disable-v2commandApril 2023 - 1 Year Post GA
docker-composetodocker composedocker-compose disable-v2command in new versionsNote: We have no plans of removing any aliasing of
docker-composetodocker compose, we want to make it as easy as possible to switch and not break any of your code.We’ll monitor feedback here alongside V2’s usage and make adjustments accordingly.
The text was updated successfully, but these errors were encountered: