Hi,

In my opinion the docker images are essentially simply differently packed
binary releases.

This becomes more true when in the future deploying a Flink application to
kubernetes simply pulls the correct binary from a docker hub. Because of
these kinds of use cases I disagree with Robert that these are just
convenience releases.

To me this means that the docker images should be released at the same time
the other artifacts are released. This also includes shapshot releases. So
the build of the docker images should be an integral part of the build.

Do note that there will be multiple sub-versions for each release with
variations in for example the used Scala version and/or JDK. All published
at the same moment.

Niels Basjes

On Mon, Apr 27, 2020, 10:26 Robert Metzger <rmetz...@apache.org> wrote:

> Thanks for starting the thread!
>
> I would consider the docker images of Flink convenience binary releases
> that can happen any time. I believe a simplified, but formal release
> process would be appropriate (preview / staging images for the community to
> validate & vote, then release to docker hub).
>
> On Wed, Apr 22, 2020 at 3:29 PM Chesnay Schepler <ches...@apache.org>
> wrote:
>
> > We can create additional releases independent of Flink, but they will
> > have to go through a formal release process in any case.
> >
> > On 22/04/2020 14:55, Ismaël Mejía wrote:
> > > Hello,
> > >
> > > I wanted to discuss about a subject that was shortly mentioned during
> > the docker
> > > unification thread (and in some other PR) that is the release of docker
> > images
> > > independent of major Flink releases.
> > >
> > > In the past when the docker images were maintained outside of the
> Apache
> > > repository we usually did intermediary releases to fix issues or to add
> > new
> > > functionalities that were independent of the Flink releases and
> specific
> > of the
> > > docker images.
> > >
> > > There are two major cases when this happened:
> > >
> > > 1. If the upstream official docker images maintainers requested us to
> do
> > the
> > >     changes or there was some breakage because some upstream change
> > (this is rare
> > >     but has happened in the past).
> > >
> > > 2. If we wanted to fix issues or add new functionality to the images
> > that was
> > >     independent of the full Flink release.
> > >
> > > We have been working on having Java 11 based images available and this
> > is an
> > > example of (2), where we want to publish these images based on the
> > already
> > > released 1.10.0 version.
> > >
> > > So I would like to know your opinion on how should we proceed in the
> > future.
> > > Ideally we should wait for the major release, but the reality is that
> > (1) can
> > > happen and (2) can benefit end users.
> > >
> > > So what should we do? Can we do these updates without a formal release
> > as we did
> > > before, or does it make sense to follow a release process with the
> > corresponding
> > > vote for the docker images? or are there other alternatives?
> > >
> > > Regards,
> > > Ismaël
> > >
> >
> >
>

Reply via email to