Adopt version numbers for tags

[agjohnson]

Currently, we have a hodgepodge of tags:

• readthedocs/build:14.04
• readthedocs/build:16.04
• readthedocs/build:beta

However, these communicate nothing about the progression of the image. Instead, perhaps we adopt semver for versioning:

• readthedocs/build:14.04 -> readthedocs/build:1.0, push to branch 1.x
• readthedocs/build:16.04 -> readthedocs/build:2.0, push to branch 2.x
• readthedocs/build:beta -> readthedocs/build:3.0, push to branch 3.x
• Add support for multiple nodejs versions -> readthedocs/build:3.1, push to branch 3.x
• Security patch release on 16.04 LTS -> readthedocs/build:3.1.1, push to branch 3.x
• New LTS release, bump 3.1.1 -> readthedocs/build:4.0, push to branch 4.x

This will allow for multiple images to exist and be pulled down to the build servers for use. The repo layout will be a single Dockerfile with multiple branches/tags to handle versions. We could even possibly rely on docker automated builds here, to cut out the middle operation of building these images on a server and pushing them up.

[ericholscher]

I think something like semvar makes sense. +1

…

On Saturday, February 4, 2017, Anthony ***@***.***> wrote: Currently, we have a hodgepodge of tags: - readthedocs/build:14.04 - readthedocs/build:16.04 - readthedocs/build:beta However, these communicate nothing about the progression of the image. Instead, perhaps we adopt semver for versioning: - readthedocs/build:14.04 -> readthedocs/build:1.0, push to branch 1.x - readthedocs/build:16.04 -> readthedocs/build:2.0, push to branch 2.x - readthedocs/build:beta -> readthedocs/build:3.0, push to branch 3.x - Add support for multiple nodejs versions -> readthedocs/build:3.1, push to branch 3.x - Security patch release on 16.04 LTS -> readthedocs/build:3.1.1, push to branch 3.x - New LTS release, bump 3.1.1 -> readthedocs/build:4.0, push to branch 4.x This will allow for multiple images to exist and be pulled down to the build servers for use. The repo layout will be a single Dockerfile with multiple branches/tags to handle versions. We could even possibly rely on docker automated builds here, to cut out the middle operation of building these images on a server and pushing them up. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABjpn0MvSUa99ji2ozkZ1S3HvRrbMdgks5rZNuHgaJpZM4L3RMX> .

-- Eric Holscher Maker of the internet residing in Portland, Oregon http://ericholscher.com

[agjohnson]

I restructured the repo and set up https://hub.docker.com/r/readthedocs/build/ as an automated build. The versions are currently built from version tags, and latest is from master, so we'll get a new image on any push to master now.