Alpine Transition - Plan Proposal

[LaurentGoderre]

Here is what I propose to handle the updating of alpine.

1. Create a alpine-3.5 branch for master
2. Create a tag on docker hub for each version (ex: v6-alpine3.5)
3. Wait a specified amount of time (2 months maybe)
4. Create a branch from master and call it alpine-3.4
5. Merge alpine-3.5 on master
6. Create a tag on docker hub for for the alpine-3.4 branch (v6-alpine3.4)
7. Keep the vX-alpine3.5 tags and switch the vX-alpine tag to point to master
8. Repeat for alpine 3.6

Any feedback on this?

[Starefossen]

Is it necessary to make a separate branch? That would complicate keeping it up to date with master until it has been merged. I mean; concider this:

We branch to alpine-3.5 branch, we submit the PR to Docker to create the v6-alpine3.5 tag, some days later a new version of Node is released, we update master submit PR to Docker and then we have to go through the same process for to v6-alpine3.5.

While I agree that using git branches for this can of this is the correct approach, I am afraid that the current process of getting tags updated on Docker Hub makes this impractical.

I very much support a strategy to managing and maintaining Alpine Linux versions in an organised fashion!

[LaurentGoderre]

@Starefossen the automated build can do all of this for us though. All we would need is manage the list of automated build. We can merge everything from master to the alpine-3.5 branch too.

[Starefossen]

I did not consider automated builds. Under what image name would you set up an automated build?

[LaurentGoderre]

Well for this plan to work I was hoping that we have access to automated builds for the node project on Docker Hub.

[nschonni]

The 8 image got bumped to 3.6
I've added some logic to the update to just use that for the 8+ image in #428