Update base images to Debian Stretch and Alpine 3.6

[yosifkit]

Bringing together other issues/PRs requesting base image updates: #428, #456, #457, #468, #482, #501.
Should fix theses once we make a PR: #495, #198

We do not want to maintain our PHP images over multiple distro releases in the long term. To update the base image without immediately breaking users like docker-library/golang#131, we'll have to release images based on all four distributions (Alpine 3.4, Alpine 3.6, Debian Jessie, and Debian Stretch) over a few months and then end of life the versions based on the older Linux distributions (Alpine 3.4 and Debian Jessie).

---

Why not keep all distribution versions longer (Alpine 3.4, 3.6, Jessie, and Stretch)?

• it takes over ~1.5 hours for travisCI to test current PRs, this would close to double that (28 uniq tags to ~49)
• it will increase update delay since the build server would also have to build the extra versions
  • this will also increase the likelihood of a tag not available for given architecture since some arches build much faster than others (like rabbitmq:3-management docker image is borked rabbitmq#188)

---

We are thinking something like this:

• release all versions and variants of the PHP images on current disto base and newer distro base (we'll use 1st November 2017 in this exploration)
  • so for example, Alpine based images would have tags for php:7.1-alpine3.4 and php:7.1-alpine3.6
  • and the Debian based images would be php:7.1-jessie and php:7.1-stretch
  • current less-specific tags would stay pointing to the older distro (php:7.1-alpine would still be alpine 3.4)
• add note about this process for future base image updates
• place large note on Docker Hub description that images based on older distributions (alpine 3.4 and debian:jessie) will be EOL in 3 months (with an exact date like 1st February 2018)
  • use deprecation notice
  • explain that generic tags like php:7.1-alpine will continue to contain Alpine 3.4 until that date and instead encourage users to switch to php:7.1-alpine3.4 to stick to a specific Linux Distro
  • they will switch over to Alpine 3.6 on that date and the same for jessie/stretch
  • remind users that 7.2 is Alpine 3.6 and stretch only
• on specified EOL date, remove Alpine 3.4 and Debian Jessie based images from the Supported List
  • users can still docker pull, but the images would no longer be rebuilt with base image changes or version bumps

I think @tianon and I could tackle something like this in the next week or two. Any suggestions or comments?

[amq]

Did some unexpected problems arise?

[amq]

https://alpinelinux.org/posts/Alpine-3.7.0-released.html

[csandanov]

Do you plan to release alpine 3.7 version for other 7.x?

[J0WI]

Where can I find the end of life dates of Alpine Linux? I didn't found any information on their website.

[tianon]

https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases

[yanbreu]

Any informations about the release date of the update for alpine 3.6 or 3.7 for PHP 7.0 and 7.1 is coming?

[teohhanhui]

It's unfortunate that -alpine doesn't point to the latest stable Alpine release. It means you're forcing users who want the latest stable to specify the Alpine version, and then it'll come back to bite them once it's EOL (or even before, when they're lagging behind being stuck with the old Alpine version for no good reason). For the common user who don't care about the Alpine version, this is bad news.

[teohhanhui]

A better alternative would be for -alpine to point to the latest stable Alpine release, and maintain each Alpine release for 3 months as you wish. So for those who require a specific Alpine version, they can stay on it until it's EOL. This would be more consistent with how the PHP releases are handled, e.g. if you choose to stay on php:7.1 instead of just php (php:7 makes less sense due to how PHP introduces breaking changes between minor versions).

[tianon]

@teohhanhui yes, with the hindsight of having done it less than ideally initially (due to not knowing what would matter longer-term), it's clear to see that -alpine should've pointed to the latest Alpine release -- that's exactly the backwards compatibility problem this issue is discussing 😉

Essentially, we need to establish that users who care about their Dockerfiles working the same long-term need to pin to a specific Alpine release, and we need to ensure that those tags are readily available. Once we've done both of those, we can easily update the plain -alpine tag to point to whatever alpine:latest does.