Update Alpine variants to 3.5

[tianon]

Closes #130

[tianon]

These all build successfully on my local machine, but we should let Travis finish so it'll run the tests as well.

[dhiltgen]

I'm worried this is going to break a bunch of downstreams... the switch from Alpine 3.4 to 3.5 is pretty significant. Would it make sense to introduce new tags instead? (for example golang:1.7.4-alpine is now 3.5 based and was 3.4 a few days ago, and at least one project I work on is broken now. I'm sure we can fix it on our side, but I'm also pretty sure others are going to get bit by this too.)

[tianon]

@dhiltgen that's true 😞

I guess in my mind, the answer to that kind of depends on how much support/maintenance Alpine 3.4 is going to receive going forward -- if it's going to be minimal, then IMO we're better off trudging forward and offering to help folks where there's breakage encountered, but if 3.4 is going to continue to receive maintenance support, then perhaps it is time to split tags further. 😕 😞

(Which is going to have to happen across a broad range of repos -- see docker-library/official-images#2508 for just the initial set to receive this same change.)

[tianon]

Perhaps @ncopa would be willing to share his thoughts too? 🙏 ❤️

[dhiltgen]

Don't get me wrong, I definitely want to migrate to alpine 3.5 - lots of goodness there, but was just caught by surprise when my CI system blew up recently. :-(

[ncopa]

We plan to support alpine 3.4 til May 2018. Maybe update alpine version at the same time as Go is getting breaking changes?

[dhiltgen]

My specific breakage was an unrelated apk package name change (by itself trivial to fix), but my bigger concern was more around unanticipated consequences... for example, we build our binaries with golaing:1.7.4-alpine, and then re-package the resulting binaries on a "plain" alpine base image, and had pinned to 3.4, but now things are out of sync. I think the safer path forward is to introduce alpine versioning into the tags for the other library images (aka, golang:1.7.5-alpine3.4) so downstream projects can control which base alpine they're using and not be surprised.

[ncopa]

I wouldn't mind if we kept golang:1.7.x-alpine on alpine:3.4 and only replaced alpine:3.5 when golang:1.8.x is out to save maintenance work.

[tianon]

Makes sense, thanks ❤️

I've already started opening a few revert PRs -- hopefully we can get this all turned back around before EOD today (PST).

[tianon]

docker-library/official-images#2508 (comment)

Full list of incoming revert PRs (so far):

• Revert "Upgrade alpine to v3.5" php#360
• Revert Alpine 3.5 upgrade in 1.11 and 1.12 (leaving 1.13 on Alpine 3.5) docker#37
• Revert Alpine 3.5 upgrade in 1.6 and 1.7 (leaving 1.8 on Alpine 3.5) #132
• Revert Alpine 3.5 upgrade in 7 and 8 (leaving 9 on Alpine 3.5) openjdk#92
• Revert "Upgrade alpine to v3.5" python#168
• Revert "Update to Alpine 3.5" ruby#108

[tianon]

... and docker-library/official-images#2513 👍

[vikstrous]

We switched to depend on alpine 3.5 as soon as the upgraded golang image was released. Does anyone still have the hash of the old manifest so we can use it as a quick way to fix our builds?

[vikstrous]

Update. Got it: golang@sha256:cfd3153a5c19d1e1637f38cc2755fae0c70aef52945b9bc81dc67f4e97a80bdb

[justincormack]

Yeah the revert has left us in a weird state, where I built stuff from 3.5 and now the base image is back to 3.4...

[tianon]

@justincormack sorry -- I tried to get the revert pushed through as fast as we could 😢

I think for this repo at least, it sounds like demand is probably high enough that we ought to consider explicit Alpine 3.5 variants for at least Go 1.7.

[justincormack]

@tianon that might be nice... in future if there is a policy it would be less unexpected, but I quite like being able to switch all my alpine base images at the same time.

[tianon]

Yeah, for Alpine 3.6, I don't think we'll even try to be quite so aggressive. 😰

(I figured 3.4 to 3.5 was going to be a smaller break than it turned out to be for folks -- won't be making that mistake twice!)

[tianon]

#134 👍

[TristanCP]

Is there a plan to give users full control on the dependency hierarchy like in Maven (You can fix explicitly the version of any transitive dependencies), or is it a non-sense to allow this with Docker images ?

If it's not a plan, it means the upper image (golang for example) has to keep his dependencies for ever (at least no change of major version) as suggest above : "golang:1.7.x-alpine on alpine:3.4 and only replaced alpine:3.5 when golang:1.8.x is out".

Moreover, it means as an operator, you can break your production installation based on Docker images at any point by pulling the exact same tag you had pulled the day before but whose dependency have changed in an uncontrollable way. For example, I pull a tomcat:8.5.11-jre8-alpine based on alpine 3.4 which is the maximum precision I can give to this tag and allows me to set precisely tomcat version and jre major version which is appropriate for a production installation. But tomorrow, with no warning, this same tag could pull an other version of Alpine which breaks my installation.