3 ms·
You're right, the logging subsystem still needs work before 1.0. We're using the RC label to indicate that we don't plan on breaking APIs and file formats in an
by shykes 12y ago
You're right, the logging subsystem still needs work before 1.0. We're using the RC label to indicate that we don't plan on breaking APIs and file formats in any major way between now and 1.0, so toolmakers and integrators can start locking down their schedule, and trust that their tools won't be deprecated in a couple months.
If it were entirely up to me I would never call it 1.0, because part of me wants it to be flawless before anybody uses it in production. But it's not up to me - a lot of people are already using Docker in production, and there are many organizations already in process of offering commercial support and services for it. Clearly they consider Docker acceptable for their needs at some level - and at some point we'll need to acknowledge that by releasing 1.0, no matter how flawed I find it to be. The improvements won't stop at 1.0 :)
- mmerickel 12y agoThat's great to hear - I've dove pretty hard into docker and love it but the logging story has been a dealbreaker for production. Decoupling "create" and "start" has been great when using the Remote API because I can create a container, attach my IO handlers, and then start, removing the need for docker to handle the logs at all (if it supported that). Possibly something like this can be done via the CLI such that docker can just forward the streams into a custom script.