I’m inclined to agree with Jeremiah and Patrick, even if it might be a steep jump from what we’ve been used to. CQL needs to be treated with the utmost care and attention to detail. Would we apply the same standard to semantic bug fixes too? Perhaps we should, where there isn’t an urgent timeline at least.
Once the dust settles from this vote, depending how it tabulates, we can see what topics like this we might need another round to nail down.
On 2 Feb 2023, at 15:56, Jeremiah D Jordan <jeremiah.jor...@gmail.com> wrote:
I think we need a DISCUSS thread at minimum for API changes. And for anything changing CQL syntax, I think a CEP is warranted. Even if it is only a small change to the syntax. On Feb 2, 2023, at 9:32 AM, Patrick McFadin <pmcfa...@gmail.com> wrote:
API changes are near and dear to my world. The scope of changes could be minor or major, so I think B is the right way forward.
Not to throw off the momentum, but could this even warrant a separate CEP in some cases? For example, CEP-15 is a huge change, but the CQL syntax will continuously evolve with more use. Being judicious in those changes is good for end users. It's also a good reference to point back to after the fact.
Patrick “ Only that it locks out of the conversation anyone without a Jira login” Very valid point I forgot about - since recently people need invitation in order to create account… Then I would say C until we clarify the scope. Thanks I think lazy consensus is fine for all of these things. If a DISCUSS thread is crickets, or just positive responses, then definitely it can proceed without further ceremony.
I think “with heads-up to the mailing list” is very close to B? Only that it locks out of the conversation anyone without a Jira login.
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) 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.
“ 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
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.
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.
|
