-
Notifications
You must be signed in to change notification settings - Fork 55
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
TODO: Upgrade Alpine base #26
Comments
Would be ok to produce both versions until we know that the new one works? |
how would we name them? how would we get people to consume and test the new ones? |
We could use the new one in the docker image. It would be a lot less risky to upgrade if we have the other version to rollback to if there's a problem |
i thinks using a newer base apine is pointless cos thi project try to compile for unsupported targets, alpine already have a official package for nodejs, so in fact is right choose using an older alpine docker base for buils so will sure the backguard compatibility with all older or midlle-recent alpine unsupported targets |
This is a TODO for someone who wants to change the recipe Dockerfiles to make them work with newer Alpine, and test that they can still build Node.js properly.
fetch-source
,musl
andheaders
all useFROM alpine:3.9
. To test an upgrade, you'd need to switch theFROM
, build images, then run containers in a way that executes their build tasks. It might be a little involved to make it work locally but hopefully by looking at the recipes it's not too unclear what needs to be done (fetch-source
is a special case recipe that's run before all the rest that simply downloads and unpacks the tarball).I think it would be safe to upgrade to 3.12, they're based on musl 1.1.x (see). while 3.13 jumps to 1.2.x(see).
We don't have a strict contract here for libc versions or any minimum level of support across major versions. We also don't currently have a mechanism to switch recipes based on Node.js major versions. So I think for now we could just do 3.12, cross our fingers a little and hope that we still produce maximally compatible binaries. Then we can make the 1.2.x jump a bit later when the ecosystem has moved on a little. The musl ecosystem is largely made up of Alpine (tho there are more), and Alpine users tend to be on much quicker upgrade cycles so give it 6-12 months and we could probably make a decent bet that folks have moved on and then we can switch to a newer Alpine with 1.2.x.
/cc @nodejs/docker
The text was updated successfully, but these errors were encountered: