Thanks the answers Eric Yang, I think we have similar view about how the releases are working and what you wrote is exactly the reason why I prefer the current method (docker image creation from separated branch) instead of the proposed one (create images from maven).
1. Not all the branches can be deprecated. Usually we have two or three branches which have large user base. Can't deprecate all but the last one. 2. Yes, release managers of the old releases are may or may not be available. 3. This is one reason to use 100% voted and approved packages inside container images: * It makes it clean what's inside (hadoop version shows that it is exactly the same bits which are voted and approved by PMC) * It makes possible to upgrade the convenience docker packaging (and not hadoop!) of older but actively used releases (eg. 3.1 today). For example in case of a serious ssl problem. * I prefer to keep container images for a few older versions. In Ozone there are tests to test the compatibility between different hadoop version. Docker containers (with older images) help a lot to test it. Marton >> 1) We need to wait until the next release to fix them (3.2.1) which >> means all the previous images would be unsecure / bad forever (but still >> available?) > > > Yes. This prevents recursive 3.2.1.1.1 version forking to be maintained by > Apache. Some company own internal decision might require them to use FROM > apache/hadoop:3.2.0 and applies their own internal patch. Apache can phase > out deprecated versions, and old version can be found in archives.apache.org >> 2) in case of a serious problem a new release can be created from all >> the lines (3.2.1, 3.1.3, 2.9.3, 2.8.6) with the help of all the release >> managers. (old images remain the same). >> > > Release manager come and go, branches will eventually die off. There is no > need to address super old images with unreachable release manager (maybe > retired). The release only happens when there is demand for it. --------------------------------------------------------------------- To unsubscribe, e-mail: hdfs-dev-unsubscr...@hadoop.apache.org For additional commands, e-mail: hdfs-dev-h...@hadoop.apache.org
