Another cloud suicide: Cloud lessons on pinning and semVer, and CI
In a nutshell, if you use ‘semVer’, you must obey:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Now I’ve been waiting (for a few years now!) for the Docker registry 2.7 to come out. Its a leisurely affair, 2.6.0 was released on 2017-01-18. The main thing I’ve been waiting for is delete to start working.
The project wandered along for a while, and then, declared it ready. Git tags were created. Oddly no Docker image was made. At the last minute they discovered that they relied on Alpine and that Alpine had no Arm version.
Lesson 1: Continuous Integration means you don’t have surprises on the last day that your 2 years of work doesn’t build.
OK, sigh, wait some more. Today GKE pushed an upgrade to our Kubernetes cluster. And, interestingly, the registry committed suicide. It wasn’t pinned (why would you when it never releases? :). OK. Interesting. Going from 2.6.2 to 2.7.0 should be compatible because semVer, right? Its not, see #2799. At the last minute a new feature was added ‘autoRedirect‘. This feature had no tests, and, more interestingly, no default value. It must be configured by the user (and False is corresponding to the old behaviour). And, no documentation. And the CI pipeline failed for but the PR was accepted.
Lesson 2: The CI fails for a reason
Lesson 3: Add unit tests, look for this in the Pull Request process
Lesson 4: Look for docs in the Pull Request process
Lesson 5: Check that new versions work with old config if they are semVer on the same MAJOR.
And, for me, Lesson 6. Thou shalt pin even when semVer suggests it should work.
IMHO this is a bit crazy, a lot of people rely on this software, and the project seems to have some major red flags. I mean, its been years and the delete has not worked. Who does that!