Currently, all images are rolling releases, i.e. all of them are automatically updated if the corresponding travis job succeeds.
On the one hand, the 'buildtest' branches (mcode, mcodegpl, llvm and gcc) run the default testsuite before pushing the images. This ensures that fundamentally broken images are not pushed to dockerhub. Still, uncaught regressions might find their way.
On the other hand, most of the images created in branches master, synth and ext are unversioned. Some of them are very experimental (most of synth), but some other are expected to be used in "production" (i.e. vunit job in ext, see ghdl/ghdl#883).
Therefore, even though users can use digests to fix their scripts to specific images, it would be desirable to include some kind of versioning. We need to think it thoroughly, tho; supporting images for simulation, synthesis and/or LSP is starting to get complex!
Currently, all images are rolling releases, i.e. all of them are automatically updated if the corresponding travis job succeeds.
On the one hand, the 'buildtest' branches (
mcode,mcodegpl,llvmandgcc) run the default testsuite before pushing the images. This ensures that fundamentally broken images are not pushed to dockerhub. Still, uncaught regressions might find their way.On the other hand, most of the images created in branches
master,synthandextare unversioned. Some of them are very experimental (most ofsynth), but some other are expected to be used in "production" (i.e.vunitjob inext, see ghdl/ghdl#883).Therefore, even though users can use digests to fix their scripts to specific images, it would be desirable to include some kind of versioning. We need to think it thoroughly, tho; supporting images for simulation, synthesis and/or LSP is starting to get complex!