5 ms·

Hi all, no World-changing features in this one, but we believe that over time, relentless incremental improvements can make a huge difference. This week we are

by shykes 12y ago

Hi all, no World-changing features in this one, but we believe that over time, relentless incremental improvements can make a huge difference. This week we are freezing all feature merges and focusing on refactoring, code cleanup and generally repaying as much technical debt as possible. We are also considering a gradual slowdown of the release cadence (we currently cut a release every month), to give more time for QA. Even though we work hard to keep master releasable at all times and run every merge through the full test suite, in practice there can never be enough real-world testing before a release. An 8-week cycle (which is roughly what Linux does) would allow us to freeze the release 1-2 weeks in advance and do more aggressive QA.

nathankleyn 12y ago
You guys are doing a fantastic job, anything that can give you a bit more of a breather between releases and increase quality is something I'm certain the community will embrace.
omglol 12y ago
This seems to be the real 1.0 release...
prudhvis 12y ago
Are you kidding?. Ability to modify /etc/hosts and specifying exact Capabilities is awesome. Thanks for the great work. I for one waited very long for this :)
- simonebrunozzi 12y ago
  Hi Solomon! I agree with prudhvis here - I think this is quite a nice add! Keep up the good work!
- darklajid 12y ago
  Now that needs to be possible in docker build: https://github.com/docker/docker/issues/1916 https://github.com/docker/docker/issues/1916 That said, yes this release looks interesting!
  - csirac2 12y ago
    Glad I'm not the only one. I maintain an embedded system and a bunch of its apps - at every point in the Docker file where mknod & friends must do their thing, I have to cut the Dockerfile right there and do docker run --privileged for that build step... and so on. It hasn't bothered me enough to comment on that issue though, Docker has really improved my workflow enormously.
ravenkat 12y ago
Currently if we restart docker daemon, all the running containers also restart. Are there any plans to keep the running containers running even if we upgrade our docker daemon?
zaphar 12y ago
I literally needed writable /etc/resolv.conf just this morning. You couldn't have timed the release any better.
tlrobinson 12y ago
ravenkat: in case you see this, it looks like you've been hellbanned. Since your question was a reasonable one, I'll copy it here: "Currently if we restart docker daemon, all the running containers also restart. Are there any plans to keep the running containers running even if we upgrade our docker daemon?"
- shykes 12y ago
  Definitely a reasonable question. The answer is yes, there are plans to do exactly that :)
hipsters_unite 12y ago
I've spent literally the last week working out restart strategies for our critical containers, so it's fair to say this has something pretty world-changing as I might be able to ship next week now. Seriously, I was writing bash wrappers to listen for exit codes and all sorts to make my own pseudo exit hooks on the host, so this is just awesome. Thanks guys!

by shykes 12y ago

nathankleyn 12y ago

You guys are doing a fantastic job, anything that can give you a bit more of a breather between releases and increase quality is something I'm certain the community will embrace.

omglol 12y ago

This seems to be the real 1.0 release...

prudhvis 12y ago

Are you kidding?. Ability to modify /etc/hosts and specifying exact Capabilities is awesome. Thanks for the great work. I for one waited very long for this :)

simonebrunozzi 12y ago
Hi Solomon! I agree with prudhvis here - I think this is quite a nice add! Keep up the good work!
darklajid 12y ago
Now that needs to be possible in docker build: https://github.com/docker/docker/issues/1916 https://github.com/docker/docker/issues/1916 That said, yes this release looks interesting!
- csirac2 12y ago
  Glad I'm not the only one. I maintain an embedded system and a bunch of its apps - at every point in the Docker file where mknod & friends must do their thing, I have to cut the Dockerfile right there and do docker run --privileged for that build step... and so on. It hasn't bothered me enough to comment on that issue though, Docker has really improved my workflow enormously.

ravenkat 12y ago

Currently if we restart docker daemon, all the running containers also restart. Are there any plans to keep the running containers running even if we upgrade our docker daemon?

zaphar 12y ago

I literally needed writable /etc/resolv.conf just this morning. You couldn't have timed the release any better.

tlrobinson 12y ago

ravenkat: in case you see this, it looks like you've been hellbanned. Since your question was a reasonable one, I'll copy it here: "Currently if we restart docker daemon, all the running containers also restart. Are there any plans to keep the running containers running even if we upgrade our docker daemon?"

shykes 12y ago
Definitely a reasonable question. The answer is yes, there are plans to do exactly that :)

hipsters_unite 12y ago

I've spent literally the last week working out restart strategies for our critical containers, so it's fair to say this has something pretty world-changing as I might be able to ship next week now. Seriously, I was writing bash wrappers to listen for exit codes and all sorts to make my own pseudo exit hooks on the host, so this is just awesome. Thanks guys!