> If versioning is done correctly, older branches can have the same docker
> subproject, and Hadoop 2.7.8 can be released for older Hadoop branches. We
> don't generate timeline paradox to allow changing the history of Hadoop
> 2.7.1. That release has passed and let it stay that way.
I understand your point but I am afraid that my concerns were not
expressed clearly enough (sorry for that).
Let's say that we use centos as the base image. In case of a security
problem on the centos side (eg. in libssl) or jdk side, I would rebuild
all the hadoop:2.x / hadoop:3.x images and republish them. Exactly the
same hadoop bytes but updated centos/jdk libraries.
I understand your concerns that in this case the an image with the same
tag (eg. hadoop:3.2.1) will be changed over the time. But this can be
solved by adding date specific postfixes (eg. hadoop:3.2.1-20190321 tag
would never change but hadoop:3.2.1 can be changed)
I know that it's not perfect, but this is widely used. For example the
centos:7 tag is not fixed but centos:7.6.1810 is (hopefully).
Without this flexibility any centos/jdk security issue can invalidate
all of our images (and would require new releases from all the active lines)
Marton
---------------------------------------------------------------------
To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org
For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
