Hi Sai and Ferenc, I'm also +1 for what you agreed on above. Looking at the current FLIP page [1], points 1 and 3 are already covered, so we don't have to duplicate the same information.
I'd suggest we add one short subsection after the process steps, e.g., "Changes after a FLIP is accepted", with the new content: - A FLIP records the design at the time it was accepted. Once implemented, the code and its user documentation are the source of truth; the FLIP page does not need to be updated for later changes. - Backward-compatible extensions to built-in SQL functions (e.g., a new optional argument) do not require a new FLIP. Use judgment and start a [DISCUSS] thread on dev@ when the user-facing impact is not obvious. Breaking changes, or changes that revisit a central decision of the original FLIP, follow the regular FLIP process. I'd scope the second point to built-in SQL functions in general rather than only PTFs. Kind regards, Gustavo [1] https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals On Fri, 2 Oct 2026 at 17:02, Krishna Sai <[email protected]> wrote: > Hi Ferenc, > > +1 to all three bullets. Thanks for stating the FLIP's role explicitly, > that > answers what I was asking, and I agree the maintenance burden would not be > worth > it. > > FROM_CHANGELOG supports your framing rather than my earlier concern. > FLIP-564 > still carries invalid_op_handling, but the shipped error_handling is fully > described in the changelog queries page - syntax, parameter table, > behaviour and > an example. A reader who follows the docs gets the current semantics. The > docs > being the contract is what makes the historical-record role safe, so I > think the > three bullets are enough as they stand. > > Best, > Sai Krishna Sepuri >
