Balancing change: feedback + learning / impact to customers = change

I was reading a post about the frustration a customer had around the constant change. First, I do apologize for the frustration as it is difficult to continually learn new things when the things you’ve learned keep changing. With each change, we balance the impact it will have on our existing customers, the challenges they’re currently facing, what we’re learning from our previous releases, and the impact we can have for new customers.
While I won’t speak for Docker, I can speak to the tooling we provide in VS, which is the same basic model Docker follows as well. The Visual Studio Container Tools are currently in beta/pre-release. With the release of VS 2017, we’ll consider this our 1.0 official release. Before we release any major release, we are willing to make significant changes. The pre-release moniker implies major changes may, or likely will occur; as we’re learning. We of course have two basic models to work with. Only release major releases, hope we get it right and deal with the consequences of not. Or, release major releases with a commitment of upgrade and support, and provide interim releases that are building up to the next major release. The interim releases are a view into what we’re thinking and doing. Many companies like Docker achieve this with beta and stable channels: As we release Visual Studio Container Tools in Visual Studio 2017, we’re working to have this same model. If you install the “stable” channel from Visual Studio, you’ll get a stable release of tools. As we release major versions, we’ll provide some sort of upgrade path. How depends on the change of course.

So, first. Thanks for all the feedback and patience. Working with containers is a major shift in how we develop software. We’re working hard to maintain the docker experience customers expect, while providing the productive experiences developers have come to expect from Visual Studio. We want to be careful to not change the the technology to match the tools, but rather shape the tools to match the technology.