You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Probably just need something like #201, but I'd like to reduce the number of variations based on a different OS.
Given that alpine:3.6 based versions of python have been out almost 6 months, I think if anything has both alpine:3.4 and alpine:3.6 variants we remove 3.4 while adding in 3.7 but make the default 3.6.
It means we should also add 3.7 variants where there is currently only 3.4 so that when 3.8 comes out we can drop 3.4 and 3.6. This will give users 1 year for each alpine release with plain alpine tags being the older of the two. I am not sure that moving the plain alpine every 6 months is the best user experience, but maybe it will push more users to use an explicit alpine version when they need it and if we put this in a doc we can have a place to point them to about the process. (We can also work out a similar strategy for all base image updates)
I understand the desire to keep the number of images to a reasonable number, but I think that removing an existing base before the upstream has been EOLed is a bad idea. One of the primary advantages of Docker is being able to do consistent builds and removing an image while upstream is still supporting it, can cause problems for a user.
Best way is support of all supported versions on this page (3.4, 3.5, 3.6 and 3.7, may be even add edge for Alpine developers) https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
As you see there is no LTS in Alpine but ~time of support is 2years,
EOL for Alpine 3.4 is 2018-05-01,
EOL for Alpine 3.5 is 2018-11-01,
EOL for Alpine 3.6 is 2019-05-01,
EOL for new Alpine 3.7 is 2019-11-01.
Remove after it become EOL'ed with line red status.
BTW, there is one specific thing needed from Alpine 3.7 -- client for PostgreSQL 10.x. Alpine 3.6 comes with PostgreSQL 9.x so some features of 10.x are not available.
My interest in 3.7 is to get headless chrome support that isn't available in 3.6. There's always going to be cases like this where Package X has been upgraded and Person Y "needs" it.
In my opinion, pulling in new features/libraries/etc is always nice (and would make my life easier in this specific case), but it shouldn't ever come at the expense removing support for existing ones that force users to do upgrades just to maintain security updates and such.
Activity
yosifkit commentedon Dec 2, 2017
Probably just need something like #201, but I'd like to reduce the number of variations based on a different OS.
Given that
alpine:3.6based versions of python have been out almost 6 months, I think if anything has bothalpine:3.4andalpine:3.6variants we remove3.4while adding in3.7but make the default 3.6.What do you think @tianon?
It means we should also add 3.7 variants where there is currently only 3.4 so that when 3.8 comes out we can drop
3.4and3.6. This will give users 1 year for each alpine release with plainalpinetags being the older of the two. I am not sure that moving the plainalpineevery 6 months is the best user experience, but maybe it will push more users to use an explicit alpine version when they need it and if we put this in a doc we can have a place to point them to about the process. (We can also work out a similar strategy for all base image updates)Alpine 3.4 is "end of support" 2018-05-01.
daveisfera commentedon Dec 2, 2017
I understand the desire to keep the number of images to a reasonable number, but I think that removing an existing base before the upstream has been EOLed is a bad idea. One of the primary advantages of Docker is being able to do consistent builds and removing an image while upstream is still supporting it, can cause problems for a user.
lorddaedra commentedon Dec 3, 2017
Best way is support of all supported versions on this page (
3.4,3.5,3.6and3.7, may be even addedgefor Alpine developers)https://wiki.alpinelinux.org/wiki/Alpine_Linux:Releases
As you see there is no LTS in Alpine but ~time of support is 2years,
EOL for Alpine 3.4 is 2018-05-01,
EOL for Alpine 3.5 is 2018-11-01,
EOL for Alpine 3.6 is 2019-05-01,
EOL for new Alpine 3.7 is 2019-11-01.
Remove after it become EOL'ed with line
redstatus.askoretskiy commentedon Dec 18, 2017
I'd say adding new Alpine versions and dropping old ones are different topics.
In my eyes, since maintenance of existing images doesn't cost anything, they should stay as long as it does not produce problems.
askoretskiy commentedon Dec 18, 2017
BTW, there is one specific thing needed from Alpine 3.7 -- client for PostgreSQL 10.x. Alpine 3.6 comes with PostgreSQL 9.x so some features of 10.x are not available.
daveisfera commentedon Dec 18, 2017
My interest in 3.7 is to get headless chrome support that isn't available in 3.6. There's always going to be cases like this where Package X has been upgraded and Person Y "needs" it.
In my opinion, pulling in new features/libraries/etc is always nice (and would make my life easier in this specific case), but it shouldn't ever come at the expense removing support for existing ones that force users to do upgrades just to maintain security updates and such.