> I don’t think it has to be all that complicated?
Definitely not. We've just never documented it afaict.
On Tue, Jun 28, 2022, at 2:58 PM, Benedict wrote:
>
> I don’t think it has to be all that complicated?
>
> If it’s a part of our UX it’s probably something we should maintain backwards
> co
I don’t think it has to be all that complicated?
If it’s a part of our UX it’s probably something we should maintain backwards
compatibility for.
If it’s part of our internal codebase, probably not. The only two “public” APIs
we have inside the codebase that I’m aware of are triggers and second
> I think it is good to document further things and keep on doing it in time
> when discussions happen. I can see this being a benefit both for users and
> Cassandra developers.
Strong +1 from me here. Having guidance for people working on the codebase to
understand what is and isn't considered
“+1 to always, by default, maintaining compatibility.”
+1
“We also have the discussion wrt what are breaking changes. Are we
intending to evolve what interfaces and behaviour we provide, and to what
degree, compatibility over via these discussions/votes?”
While I do agree we cannot really have a
We've agreed in the past that we want to maintain compatibility and that
> all changes will be done with compatibility in mind (see
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle),
> but we haven't clarified how we make the call on when to bump to next
> major.
>
+1 to
compatibility – even if we already have bumped major version.
>>
>> A major version bump should NOT be taken as carte blanche to break users, we
>> should determine it for eadh case on a balance of benefit/cost.
>>
>>
>>
>> From: Mick Semb Wev
users, we
> should determine it for eadh case on a balance of benefit/cost.
>
>
>
> From: Mick Semb Wever
> Date: Wednesday, 15 June 2022 at 17:44
> To: dev@cassandra.apache.org
> Subject: Re: Cassandra project biweekly status update 2022-06-14
>
> I
should NOT be taken as carte blanche to break users, we
should determine it for eadh case on a balance of benefit/cost.
From: Mick Semb Wever
Date: Wednesday, 15 June 2022 at 17:44
To: dev@cassandra.apache.org
Subject: Re: Cassandra project biweekly status update 2022-06-14
I'm going to j
>
> I'm going to jump off the email list to JIRA for this one - we've had a
> discussion ongoing about when we cut a Major vs. a Minor, what qualifies as
> an API, etc on CASSANDRA-16844 (
> https://issues.apache.org/jira/browse/CASSANDRA-16844). Expect something
> to formally hit the dev mailing l
There are 3 view filtering test failures in the 8 4.1 failures which are
known offenders as being parametrized they might take long in an
overloaded systems. Once we're back to normal capacity on jenkins they
should be ok, finger in the air estimate, so we might be even better
than 8. #collabor
How has it been two weeks already?
4.1 is high priority, so let's start there:
https://butler.cassandra.apache.org/#/
Last run had 8 failed tests! We've had a pretty painful run in terms of CI
infrastructure over the past week on 4.1 (see here:
https://ci-cassandra.apache.org/job/Cassandra-4.1/
11 matches
Mail list logo
