Create different package names based on Alpine version

[jnardone]

Upon clearing our caches out and rebuilding our Docker containers, we realized that ruby:2.3.1-alpine is now based on Alpine 3.4 vs 3.3. This pointed out some changes in package dependencies between those versions.

There should be package names that include the Alpine version, so that we can make an explicit choice of when we move from (say) 3.3 to 3.4. Right now, the definition of the ruby 2.3.1-alpine dockerfile can change without any indication that it's changed OS versions, which seems bad from a repeatable process standpoint.

[yosifkit]

I feel like this would lead to maintaining even more versions of ruby, since users would want the Alpine 3.4 and 3.3 series of Ruby to be updated. Package differences between the versions of Alpine is not the only issue that can arise; there could easily be a problem with the installed RubyGems or Bundler versions which are also not in the docker tag.

If you need to ensure repeatable builds then I suggest pulling by digest (https://docs.docker.com/engine/reference/commandline/images/#/listing-image-digests), so that you can control when any change occurs not just Alpine base changes.

Edit: There is a growing history of ruby image digests in tag-details.

[tianon]

Another option is to take known-good images and re-tag them into your own repository so that you control your "base image update" story more directly (and can further vet the images before "promoting" them).

[rafaelgaspar]

I like the approach golang had for this issue, for the current version of go they have a 3.4(1.7.5-alpine tag) and a 3.5(1.7.5-alpine3.5 tag), for the new release 1.8 they only have 3.5 alpine tag, the reason for this is, if there is going to be breaking changes it should be on major releases.

Python is looking on that direction too.