[wildfly-dev] Future of WildFly Docker image

Hi, As you know, WildFly is providing a Docker image for each release of WildFly from the jboss organization at https://hub.docker.com/r/jboss/wildfly/tags. However hub.docker.com has recently changes their features and we are no longer able to automate new images whenever we tag our GitHub project at https://github.com/jboss-dockerfiles/wildfly. This is becoming a manual task that only a few people in jboss organization can do. We are trying to find a new way to deliver these images in a sustainable fashion. One approach would be to move the Docker images to quay.io which provides the basic features we need to build images from our GitHub repo. We already have a wildfly organization on Quay.io (that provides our S2I images as well as the WildFly operator): https://quay.io/organization/wildfly This would affect users that pulls our images as they would have to use FROM quay.io/wildfly/wildfly instead of FROM jboss/wildfly Internally, there would be no changes: we would continue to build these Docker images from tags in https://github.com/jboss-dockerfiles/wildfly The latest release for our Docker image was the 25.0 tag. A transition would be: 0. Advertise that we will stop delivering images from hub.docker.com. At this point, the jboss/wildfly:latest tag will point to 25.0 and will no longer be in sync with new WildFly releases. 1. Set up the quay.io/wildfly/wildfly repo and push the 25.0 tag to it. -> users can switch from "jboss/wildfly” to "quay.io/wildfly/wildfly” without any impact for their applications 1.a If we eventually release images for 25.0.x versions, we will push images to both hub.docker and quay.io repositories 2. When we release the next major version of WildFly (WildFly 26), the image will be made available only from "quay.io/wildfly/wildfly” with the 26.0 and latest tag Does that approach sounds sensible? Best regards, Jeff -- Jeff Mesnil Principal Software Engineer Red Hat http://jmesnil.net/