Hi everyone,
Thanks a lot for all your input. I hope that I could answer most of the
questions. I would now start a vote on this FLIP.
Cheers,
Till
On Tue, Dec 7, 2021 at 3:05 PM Till Rohrmann wrote:
> Hi Timo,
>
> 1) I haven't fully thought where to put it but I guess that flink-core
> might
Hi Timo,
1) I haven't fully thought where to put it but I guess that flink-core
might be a good place for the FlinkVersion. We should then also unify any
other enums if possible.
2) I think it makes sense to also review our deprecation process. I think
it makes a lot of sense to add since when
Hi Till,
thanks for starting this discussion. I think this topic should have been
discussed way earlier. I have two questions:
1) It might be an implementation detail but where do you expect this
`FlinkVersion` to be located? This is actually a quite important class
that also needs to be
Ok, then lets increase the graduation period to 2 releases. If we see that
this is super easy for us to do, then we can shorten it in the future.
Cheers,
Till
On Mon, Dec 6, 2021 at 9:54 AM Chesnay Schepler wrote:
> Given that you can delay the graduation if there is a good reason for
> it, we
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
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
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 wrote:
> Hi Till,
>
> Overall I whole-heartedly agree with the proposals in this FLIP. Thank you
> for
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
Thanks for the feedback Konstantin.
* I agree that if we think that one release cycle to graduate is too short,
then we should extend it to something we believe we can achieve. For
FLIP-27, I think we could have stabilized the API faster if it had been our
priority (not sure whether two release
Hi Till,
This makes sense to me, in general. I am wondering two things:
* is one release to promote enough or will it lead to a lot of exclusions?
FLIP-27, for example, took much longer to stabilize, I believe. If we
think, this is quite a strict rule, then in my experience, let's rather
start
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
11 matches
Mail list logo
