Last month, when people upgraded their K8S clusters to use Engine 1.13, networking broke for them
because the default forwarding policy changed to `DROP` to increase the security and prevent some
specific network attacks. After a [long discussion on Twitter](https://twitter.com/jbeda/status/826969113801093121)
we realized that while the 1.13-rc releases had been out for months, they hadn't received as much
testing as we wanted because they hadn't been announced through all available channels.
This is a proposal to alter the release process to make sure that release candidate versions are
announced as widely as possible.
Signed-off-by: Jerome Petazzoni <jerome.petazzoni@gmail.com>
The AUTHORS file should be updated before
each release, and updated using only the
commits that are in the release branch.
This adds updating the file to the release
checklist.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Add some missing dependencies in the Dockerfile:
- apt-utils for apt-ftparchive.conf
- bsdmainutils for our use of the column command in
hack/make/generate-index-listing
We also ensure that the docker daemon is started before calling
release-deb or release-rpm, since .detect-daemon-osarch, which is sourced
in each of them, requires the daemon to be running.
This commit also gets completely rid of s3cmd and fixes references to
AWS_* environment variables (changing from AWS_ACCESS_KEY to
AWS_ACCESS_KEY_ID and AWS_SECRET_KEY to AWS_SECRET_ACCESS_KEY) in order
to please awscli. Also AWS_DEFAULT_REGION is now important to specify,
the default has been set to the region used by get.docker.com and
test.docker.com.
Signed-off-by: Tibor Vass <tibor@docker.com>
Bump both API and VERSION directly after the release
branch is created. All changes to master after that
are (by default) for the *next* release.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Rather than keeping a branch named "release" where we merge every release,
we want to keep "disposable" release branches for each release.
This will make much easier to create new major releases, since we always
want to start these releases from what we have in master. We create a
disposable release branch from master that we'll only use during the lifecycle
of the major release.
Once the release branch is created, the release captain will use a "bump" branch
in her own fork to cherry pick changes that will need to be applied to this
release. We'll track those changes in a pull request between the disposable release
branch and the bump branch.
Signed-off-by: David Calavera <david.calavera@gmail.com>
Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au>
Docker-DCO-1.1-Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au> (github: SvenDowideit)
Signed-off-by: Sven Dowideit <SvenDowideit@docker.com>
We might want to break it up into smaller pieces (eg. tools in one
place, documents in another) but let's worry about that later.
Signed-off-by: Solomon Hykes <solomon@docker.com>
