Git tags tie each Docker container to a stable Docker tag. This will look like this in the `docker-compose.yml`
```shell
$ grep '^[[:space:]]*image:' docker-compose.yml
image: cytopia/bind:0.9
image: cytopia/${PHP_SERVER:-php-fpm-7.0}:0.9
image: cytopia/${HTTPD_SERVER:-nginx-stable}:0.9
image: cytopia/${MYSQL_SERVER:-mariadb-10.1}:0.9
```
That means within your current git tag, you will not receive any Docker container updates, because the devilbox is bound to specific Docker tagged versions.
When a new devilbox tag is released, the `docker-compose.yml` file will have new Docker tags. There is no manuall action required. If you start up the devilbox for the first time, it will see that the container with those tags are not available locally and automatically start downloading them.
The git master branch ties each Docker container to their `latest` tag. Latest tagged Docker container always reflect the latest changes and can be compared with a master branch of a git repository. This will look like this in the `docker-compose.yml`
When you update the devilbox repository by `git pull origin master`, the Docker tags are still `latest` and you will continue using the current version of Docker container. You must also issue `docker-compose pull` in order to also update your Docker container.
New devilbox releases will most likeley receive new or improved functionality and features and therefore will have an altered `env-example` file. (This is an example configuration file which holds all current configuration options).
The effective configuration for docker-compose is stored in the `.env` file. However, the `.env` file is ignored by git, so that you can do changes without setting the git state dirty.
So when you update (master branch or tag) you will always have to compare your current `.env` settings with the new `env-example` file. If you are familiar with vim, just do the following:
```shell
$ vimdiff .env env-example
```
Make sure to transfer all new options from `env-example` to your current `.env` file.
As described above, for git master branch updates you will always have to pull new Docker container. **However, there is something very important to keep in mind:**
1. You have just updated the master branch and pulled new Docker container
2. You edit the `.env` file to switch to a different PHP version
3. You start up the devilbox. Is your new PHP Docker up to date?
No! You will have to `docker-compose pull` again. Why?
As you can see, the Docker container names are variablized. If you updated `php-fpm-5.4:latest`, you still have to update `php-fpm-5.5:latest` (and all others) as they were not yet enabled/visible in `docker-compose.yml`.
So instead of pulling everything manually, use the bundled update script to do that for all available Docker container. That will also allow you to work offline, as every available docker image will be download in their latest version.
The devilbox is not yet at a feature-ready stable release and volumes mounts might change from release to release until version 1.0 will be released. This can cause errors during startup. To solve those issues after updating, you should remove all anonymouse volumes with the following command: