While I do agree with you, I am thinking that if we include many things that we would expect lazy consensus on I would probably have different preference.
I definitely don’t mean to stall this though so in that case: I’d say combination of A+C (jira with heads up on the ML if someone is interested into the jira) and regular log on API changes separate from CHANGES.txt or we can just add labels to entries in CHANGES.txt as some other projects. (I guess this is a detail we can agree on later on, how to implement it, if we decide to move into that direction) On Thu, 2 Feb 2023 at 8:12, Benedict <bened...@apache.org> wrote: > I think it’s fine to separate the systems from the policy? We are agreeing > a policy for systems we want to make guarantees about to our users > (regarding maintenance and compatibility) > > For me, this is (at minimum) CQL and virtual tables. But I don’t think the > policy differs based on the contents of the list, and given how long this > topic stalled for. Given the primary point of contention seems to be the > *policy* and not the list, I think it’s time to express our opinions > numerically so we can move the conversation forwards. > > This isn’t binding, it just reifies the community sentiment. > > On 2 Feb 2023, at 13:02, Ekaterina Dimitrova <e.dimitr...@gmail.com> > wrote: > > > > “ So we can close out this discussion, let’s assume we’re only discussing > any interfaces we want to make promises for. We can have a separate > discussion about which those are if there is any disagreement.” > May I suggest we first clear this topic and then move to voting? I would > say I see confusion, not that much of a disagreement. Should we raise a > discussion for every feature flag for example? In another thread virtual > tables were brought in. I saw also other examples where people expressed > uncertainty. I personally feel I’ll be able to take a more informed > decision and vote if I first see this clarified. > > I will be happy to put down a document and bring it for discussion if > people agree with that > > > > On Thu, 2 Feb 2023 at 7:33, Aleksey Yeshchenko <alek...@apple.com> wrote: > >> Bringing light to new proposed APIs no less important - if not more, for >> reasons already mentioned in this thread. For it’s not easy to change them >> later. >> >> Voting B. >> >> >> On 2 Feb 2023, at 10:15, Andrés de la Peña <adelap...@apache.org> wrote: >> >> If it's a breaking change, like removing a method or property, I think we >> would need a DISCUSS API thread prior to making changes. However, if the >> change is an addition, like adding a new yaml property or a JMX method, I >> think JIRA suffices. >> >> >>
