Skip to content

Tags alpine and *-alpine should refer to latest alpine release 3.7, not 3.4 #265

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
berndverst opened this issue Feb 28, 2018 · 4 comments
Closed
Labels
Request Request for image modification or feature

Comments

@berndverst
Copy link

berndverst commented Feb 28, 2018

I am requesting that the alpine related tags without explicit version always refer to the latest stable alpine release. Currently this should be 3.7.

In https://github.com/docker-library/python/blob/master/generate-stackbrew-library.sh#L17 this already seems to be done. But it's unclear to me why Python 3.6 is explicitly being mapped to Alpine 3.4:
https://github.com/docker-library/python/blob/master/generate-stackbrew-library.sh#L22

defaultAlpineVersion='3.7'
declare -A alpineVersions=(
	[2.7]='3.4'
	[3.4]='3.4'
	[3.5]='3.4'
	[3.6]='3.4'

Desired: 3-alpine and alpine (and any other -alpine) tags should used latest stable python and alpine releases. Currently that is Python 3.6.4 and Alpine 3.7.

Current: 3-alpine and alpine tags use Alpine 3.4, several versions behind.

@berndverst
Copy link
Author

Thoughts on this @yosifkit @JayH5 @tianon ?

@berndverst berndverst changed the title Update 3-alpine and alpine tags to use latest stable alpine release Tags 13-alpine and alpine` tags should refer to alpine 3.7, not 3.4 Feb 28, 2018
@berndverst berndverst changed the title Tags 13-alpine and alpine` tags should refer to alpine 3.7, not 3.4 Tags 3-alpine and alpine` tags should refer to alpine 3.7, not 3.4 Feb 28, 2018
@berndverst berndverst changed the title Tags 3-alpine and alpine` tags should refer to alpine 3.7, not 3.4 Tags alpine and *-alpine should refer to latest alpine release 3.7, not 3.4 Feb 28, 2018
@myoung34
Copy link

myoung34 commented Apr 4, 2018

This would solve some issues I'm having with versions in the 3.4 container

@michael-k
Copy link
Contributor

I am requesting that the alpine related tags without explicit version always refer to the latest stable alpine release.

This should be changed for all other tags, too. Eg. 3.6 should be an alias for 3.6.5-stretch and not 3.6.5-jessie.

But it's unclear to me why Python 3.6 is explicitly being mapped to Alpine 3.4

When 3.6-alpine was initially published on the docker hub, there were no images with tags that pinned the alpine version, ie. there was no 3.6-alpine3.x. When the tags were introduced, 3.6-alpine stayed pinned to Alpine 3.4 to guarantee stability for existing users.
See docker-library/golang#131 and the linked issues for examples where an update of alpine led to issues.

ruby:2.4-alpine is also an alias for ruby:2.4-alpine3.4 and golang:1.9-alpine is an alias for golang:1.9-alpine3.6 (both instead of 3.7).

That said, I think that at some point most users aiming for stability should have discovered the new tags and switched to one of them. And them 3.6-alpine should become a rolling tag (like debian:stable or ubuntu:rolling). Ideally this should be done hub wide and not on a per image basis (for consistency), but then there are official images like node that haven't made the switch to the new tagging schema.

And last but not least, I think that anyone aiming for stability should build their own python image. I consider official images as a source for best practices, not a source for stability, but maybe the majority of docker users thinks otherwise.

@bmw
Copy link

bmw commented Apr 20, 2018

What's the plan for the *-alpine images when support ends for Alpine 3.4 in a couple weeks?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request Request for image modification or feature
Projects
None yet
Development

No branches or pull requests

5 participants