Work out a Docker image release schedule

[Jack Hale]

With quay.io we can use tags to permanently mark releases. So we can have quay.io/fenicsproject/stable:1.6.0 tagged up before we move to 1.7.0 in a few weeks.

However, quay.io do (politely) ask that you don't keep around millions of unused and pointless tags, as they can take up a lot of space. So having stable:1.6.0r15 where r15 refers to say a single build of the docker image on a random day seems unnecessary.

Thoughts?

[Prof Garth Wells]

I think one image for the release, with no auto-build.

What about base images that quay.io/fenicsproject/stable:1.6.0 builds off? Will these be automatically 'rolled' into quay.io/fenicsproject/stable:1.6.0, or do we need to keep the base images around?

[Jack Hale]

Yep, if we tag stable:1.6.0 on quay.io the whole stack will be stored. So, it should in theory be possible to run 1.6.0 in many years time. As a way of keeping a historical archive of working FEniCS releases around, I think this is a very nice method.

Before the shift over to 1.7.0, I will tag one of the final automatic builds of 1.6.0 as stable:1.6.0. I will tag the first build of 1.7.0 that I am satisfied with stable:1.7.0. The open question is whether we should also have a couple of tagged images through the lifecycle of 1.7.0, e.g. stable:1.7.0r1 and stable:1.7.0r2 as we make tweaks to the Docker images like upgrading PETSc and SLEPc.

[Jack Hale]

Happy with the stable:yyyy.v.p.rx scheme, e.g. stable:2016.1.0.r2. Compatible with Python naming. Flexibility to change in the future, no problem with having multiple tags pointing at one image. Only going to do tagging with stable developers are perfectly able to tag their own images locally if they want to.