Given that you can delay the graduation if there is a good reason for
it, we should be able to cover that case even if the graduation would
happen by default after 1 month.
That said, personally I would also be in favor of 2 releases; we see
plenty of users not upgrading to every single Flink version, and this
may give us a bit more coverage.
On 06/12/2021 09:20, Ingo Bürk wrote:
Hi Till,
from my (admittedly limited) experience with how far projects lag behind in
terms of Flink versions – yes, the combined time it would take to mature
then seems reasonable enough for a sufficient adoption, IMO.
Another reason why I think two releases as a default for the last step
makes sense: say you mature an API to PublicEvolving. Typically, there will
be issues found afterwards. Even if you address these in the very next
release cycle, a duration of one release would mean you fully mature the
API in the same release in which things are still being fixed; intuitively,
it makes sense to me that the step to Public would come after a period of
no changes needed, however.
Ingo
On Fri, Dec 3, 2021 at 4:55 PM Till Rohrmann <trohrm...@apache.org> wrote:
Hi Ingo, thanks for your feedback.
Do you think that two release cycles per graduation step would be long
enough or should it be longer?
Cheers,
Till
On Fri, Dec 3, 2021 at 4:29 PM Ingo Bürk <i...@ververica.com> wrote:
Hi Till,
Overall I whole-heartedly agree with the proposals in this FLIP. Thank
you
for starting this discussion as well! This seems like something that
could
be tested quite nicely with ArchUnit as well; I'll be happy to help
should
the FLIP be accepted.
I would propose per default a single release.
The step from PublicEvolving to Public feels more important to me, and I
would personally suggest making this transition a bit longer. We have a
bit
of a chicken-egg problem here, because the goal of your FLIP is,
ultimately, also to motivate faster adoption of new Flink versions, but
the
status quo prevents that; if we mature APIs too quickly, we risk losing
out
on important feedback. Therefore, I would propose starting slower here,
and
rather think about shortening that cycle in the future.
Best
Ingo
On Thu, Dec 2, 2021 at 3:57 PM Till Rohrmann <trohrm...@apache.org>
wrote:
Hi everyone,
As promised, here is the follow-up FLIP [1] for discussing how we can
ensure that newly introduced APIs are being stabilized over time. This
FLIP
is related to FLIP-196 [2].
The idea of FLIP-197 is to introduce an API graduation process that
forces
us to increase the API stability guarantee unless there is a very good
reason not to do so. So the proposal is to reverse the process from
opt-in
(increasing the stability guarantee explicitly) to opt-out (deciding
that
an API cannot be graduated with a good reason).
Since every process breaks if it is not automated, we propose a richer
set
of API stability annotations that can capture enough information so
that
we
can implement a test that fails if we fail to follow the process.
Looking forward to your feedback.
Hopefully, we can provide our users a better experience when working
with
Flink because we offer more stable APIs and make them available faster.
[1] https://cwiki.apache.org/confluence/x/J5eqCw
[2] https://cwiki.apache.org/confluence/x/IJeqCw
Cheers,
Till
