I have added a second branch "prerelease" to this repo to download the release candidate zip files of Docker Client and build prerelease chocolatey packages for them.

Do not merge this branch into master. AppVeyor will build this prerelease branch and runs a choco push.

The delta between master and prerelease should keep in seperate branches, so it's easier to build 1.11.0 in master, then later on build 1.11.1-rc1 in prerelease, then 1.11.1 in master again ...

Pull requests for new prerelease should be created against the prerelease branch, of course.

And yes while writing this AppVeyor has pushed the first prerelease package to Chocolatey: https://chocolatey.org/packages/docker/1.11.0-rc4

@StefanScherer I'm planning to change my username to ahmetb, do you foresee any problems with this repo and its integration with Chocolatey?

There is some confusion for Windows users what choco install docker does.

As we have several other Chocolatey packages for Windows developers installing a Docker engine on their machines:

• docker-for-windows - both the stable and edge channel (with option -pre)
• docker-toolbox - for VirtualBox (and maybe VMware) users

For the real server installation there is no choco package, this might be eg. docker-ee if someone wants to take this task (using the steps from https://store.docker.com/editions/enterprise/docker-ee-server-windows).

To make this choco package more clear it really would help to rename it to docker-cli, make all the CLI versions available and either unlist the docker packages or make the docker package an universal package for Desktop and Server experience.

A comment from Rob Reynolds in a Slack channel about this:

package parameters could determine what all to install or not install
I would see maybe docker package moving to docker-cli and docker would take a dependency on it

My answer:

Thanks for the advice. Moving docker to docker-cli seems a reasonable idea to make it more clear what to expect. I guess the high download rate for “just” the cli results in the assumption to get “all of that Docker” 🙂
Do you have any advice to to make that transition to rename a package that users’ have already installed?
The other thing is: Docker, Inc. doesn’t provide Docker CLI binaries any more. 17.10 was the latest zip file. So the “docker” package sooner or later will be deprecated.

Rob's answer:

deprecation strategies are important
if the original item went away, provide a way to get to it as docker-cli
then carry what docker should be in the package