A propos de la politique de versions des images

README.md

@@ -183,14 +183,17 @@ ou au sein d'un conteneur.
 
 ## Faire une image spécifique au plongeon
 
-Ajouter un Dockerfile dans votre répertoire.
+Plutôt que de faire une image de façon interactive avec un
+"docker commit", privilégiez la création d'un `Dockerfile`, à stocker
+dans le répertoire du plongeon, afin que tout le monde sache comment
+refaire cette image.
 
 J'ai bien aimé cette [présentation sur Dockerfile](http://putaindecode.io/fr/articles/docker/dockerfile/).
 
 Si vous voulez vous protéger des éventuels problèmes de montages de volume
-des utilisateurs Windows, vous pouvez intégrer à votre image une copie des
-fichiers de votre répertoire, ainsi que des outils d'édition. Par exemple,
-pour fabriquer `piscineri3/gcc61` en version 2 :
+des utilisateurs Windows (à priori réglés à ce jour), vous pouvez intégrer à
+votre image une copie des fichiers de votre répertoire, ainsi que des outils
+d'édition. Par exemple, pour fabriquer `piscineri3/gcc61` en version 2 :
 
 ```
 FROM gcc:6.1
@@ -233,6 +236,20 @@ docker login
 docker push piscineri3/gcc61:2
 ```
 
+A propos de la politique de versions des images,
+deux options se présentent :
+1. Vous utilisez "latest" : vos nageurs n'ont pas besoin de surveiller
+les versions de vos images, n'y même d'être conscients qu'il y a
+une notion de version. Par contre, il faut veillez a leur faire
+refaire des `docker pull...` fréquents, pour garantir qu'ils ont
+bien téléchargé la dernière version (`docker run...` ne vérifie pas
+la confirmité de l'image locale par rapport à celle du hub).
+2. Vous utilisez des noms explicits, tels que "v1" : vous devez remettre
+à jour vos énoncés à chaque modification de vos images, et vos nageurs
+doivent apprendre la notion de version d'image. Par contre, vous
+êtes protégés contre le cas d'un nageur qui n'aurait pas la
+bonne "latest".
+