Tag Versioning

[Nemo64]

So as mentioned in #31, I kind of dislike that changes like new extensions etc get pushed into old tags and potentially break old projects or make the version I run on my machine different from the version a co-worker runs on his machine.

So I see a few ways to do this I could think of.

• add the minor php version to the tag and continue like now ~ just don't update old tags. This would result in the cleanest tags and would be consistent with the base php repository chialab/php:7.1.9-fpm. This could potentially break new projects that pin on the newest php release but since they are still new this shouldn't be a problem ~ my concern is about legacy projects.
• add a chialab version. This would make updates kind of complicated since you'd now have to track 2 versions. Also I don't now how to make that look nice.

[fquffio]

Hi @Nemo64 ! Sorry for replying with such a delay, but I've been kinda busy these days.

I'd rather not add another versioning system on top on PHP's one. So, I'd go with the first option you have proposed.

I was thinking of a third option, too, but I'd like to gather some feedback for it. We might continue tagging the way we do, and additionally tag each image with the hash of the commit it was built from. So:

• chialab/php:7.1 is also tagged as chialab/php:7.1-abcdef01
• chialab/php:7.1-fpm is also tagged as chialab/php:7.1-abcdef01
• chialab/php:latest is also tagged as chialab/php:latest-abcdef01 (or chialab/php:abcdef01?)

This way, for the people feeling adventurous out there, the existing tags would do just fine, but builds could be broken from time to time in case some clumsy maintainer (cc @fquffio) doesn't think twice before committing. For those requiring a bullet-proof^{[citation needed]} foundation, commit-tagged images would be the best option.

In any case, we would likely need to change the way images are published on Docker registry: right now images are built on Travis CI just for the purpose of testing, and built on Docker Cloud to be distributed. Tagging options on Docker Cloud, however, are a bit limited, so we would probably need to push the images built in Travis. Circle CI has a good support for Docker, too, so we might evaluate if it's worth switching.

[Nemo64]

Your third way is basically my second way except with a checksum instead of a version. I honestly don't know whats best.

I don't think a checksum or version is pretty but it would resolve all my concerns. I could just pin down to a checksum and 7.1 and get (depending on my local cache) some php 7.1 version with the capabilities i pinned down on and if there is a new php extension added that i need, i'll update my checksum and therefor enforce that everyone using my project has to download a new version because of the tag mismatch.

The hash is just VERY long. fc79d4924f7454d55fa9c893061ced1ab452359a is the latest commit. It probably should at least by the short version fc79d49 with the hope of it never conflicting.

[fquffio]

I'd use the short version. Basically what git rev-parse --short HEAD prints to stdout.

According to Git docs, this returns always a unique prefix of at least N characters — on my system default is 7, we could choose to use 8. It is not guaranteed that the returned prefix won't conflict with something in the future, but it is guaranteed that it does not conflict with anything in the past, so it should do the work.

E.g.: if at some point in time we release tag 7.1-abcdef0, when we have another commit with a SHA that begins with the same prefix, the tag would be 7.1-abcdef01.