Image Versioning & Deprecation Plan

[grayside]

Node 4 and Bower are both hurtling rapidly towards deprecation, but we have existing projects that will depend on them for awhile yet.

EDIT: We also have the potential to drop Ruby as a default dependency, as a significant majority of projects do not use it and if utilities come up as necessary they could perhaps be implemented as customizations instead.

Deprecation Plan

1. Introduce a versioning scheme.
2. Add an s6 script that warns users to update to a specifically tagged version with a recommendation to use if they need bower and/or node 4.
3. Tag the image with that version.
4. Make announcements about a B/C break
5. Cut a 1.x branch of the repo and update any autobuilds to point to that branch instead of master.
6. Move forward dropping the deprecated stuff.

Versioning Scheme

I propose a versioning scheme of ".-<lang.version>", with the result in projects of outrigger/build:2.0-php71. (Given this pattern, the version we recommend legacy projects switch to will be outrigger/build:1.0-php70 or the like.)

1. Since we have a flattened repository system, we tag git with "v2.0"
2. We configure builds by tag in Docker Hub to get the Docker tag 2.0-php71.
3. We keep in mind we'll have a long tail of projects where teams do not worry about shifting versions of docker images as long as they do not need to edit config, but now we are asking them to edit config.
4. We might choose to add support for a "dev" tag, which is basically explicitly declared latest but makes it easier to test merged changes ahead of a release.
5. If we want to support a legacy in addition to the 1.x branch, we would have breathing room to allow projects to disable the warning message with an env var, but only after they switch to deterministic versioning.

This is loosely the pattern I setup with outrigger/keel, without the language-specific extension.

Full Set of Tags

• php55
• php56
• php70
• php71
• 1.0-php56
• 1.0-php70
• 1.0-php71
• 2.0-php56
• 2.0-php71

In this set of tags, I am demonstrating officially unsupporting PHP 5.5 and deprecating PHP 7.0.

EDIT: Added example tags, added a bullet to the bottom of Versioning Scheme about making the warnings disable-able, since warning output on build container operations is maddening and if a project legitimately needs to keep on Node 4 or Bower for a while we should have some mercy.

[tekante]

This seems reasonable. Would the intention be that we'd use the S6 script to detect if someone is using an item that we're thinking of deprecating and warn in that case?

At some point it would be great if we could get to where we don't have to include every version of certain toolsets (node I'm looking at you). In that case would you see the versions being something like build:2.0-php71-node8-...?

[grayside]

For purposes of the s6 script, we could certainly issue deprecation warnings that way, but part of the idea is that if we associated the Docker tag php56 to be implicitly the 1.x branch, we could leave a blanket "please switch to 2.0-php56" deprecation warning, and even in-line the breaking changes there to help developers quickly evaluate if it would be okay to make it a quick change.

I agree that we should get to the point of 3.0-php71-node8. I don't see it happening in a v2 major, because I don't see us going to a 2-axis matrix until we switch to dynamically building Dockerfiles based on those combinations. We have an Ansible-related approach slowly cooking, but it may be worth looking at a simple templating approach as part of a compilation step we manually run before committing changes.

Actually, on second thought, I could see us going to that versioning scheme sooner, as we could conceivably create simple Dockerfiles that just override the NODE_VERSION default env. We'd still have nvm and 3 versions of node however.

[tekante]

I don't think it's a critical thing to have the multiple versions, just curious if you had thoughts around the naming. If it doesn't save space on the images having a different version be the default I don't think warrants differential tagging at the moment.

[febbraro]

We can also investigate the use of ARG and parameter use the builds to get the variety we want. We would then transition off of automated builds and have something like Travis build for us.

[grayside]

That dovetails nicely with testing all PRs. Let's take up build process and node support in a follow-up, unless its a prerequisite for v2?