When do we roll a new version of our images?

As of yesterday, we now have a couple new image tags up for [Clowder on Docker Hub|https://hub.docker.com/r/ndslabs/clowder/tags/]:

  • develop: This image will pull and run the newest build of the develop branch.
  • 0.9.1: This image will run the code currently on the HEAD of the "master" branch. As I understand it, this represents the current release.
  • latest: This image should always point to the newest release of the code (i.e. not including develop)

When changes are pulled into master and/or a new tag is created for a new release, we can rebuild this image and push a new version tag for it.

NOTE: There is a tag on github for v0.9.1 (along with some others that do not follow the same semantic versioning format) but the existing Dockerfile pulls from Bamboo and not BitBucket. In order to use this tag, we would need to modify the clowder Dockerfile to check out and build the code on BitBucket. This is still a viable option if we plan to version from tags going forward, but seems excessive if release tags are not a standard practice.

Is there potentially a better pattern for parameterized images?

Yes there is!

Currently, the entrypoint script uses many Environment Variables in order to discover which plugin it should enable.

Instead, when a new instance of Clowder is configured, its configuration files (play.plugins and/or custom.conf) can be generated on deployment and stored in etcd. This will prevent the entrypoint script from needing to build up its own config files and persist them between pod restarts, while also allowing the user to select / customize their installation of Clowder.

Versioning scheme?

Currently, for Clowder we are sticking with the current versioning scheme and disregarding the branch/build portion on our end.

Since the extractors have no concrete versions / tags set, we have arbitrarily set their initial image versions to match that of Clowder's current release: *0.9.1*.

Semantic Versioning

In general, version numbers will be formatted as X.Y.Z where:
X = Major Version Number - For any API removals or modifications (i.e. api-breaking changes), we roll this number forward
Y = Minor Version Number - For any API additions (not removals), we roll this number forward
Z = Revision Number - For any bug fixes and non-api-changing improvements, we roll this number forward

  • No labels