Hi Niels,
I think Robert was referring to the fact that Apache considers only the
source release to be "the release", everything else is called
convenience release.
Best,
Aljoscha
On 27.04.20 19:43, Niels Basjes wrote:
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
