You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Štefan Miklošovič <sm...@apache.org> on 2024/06/20 16:46:08 UTC
Suggestions for CASSANDRA-18078
List,
we need your opinions about CASSANDRA-18078.
That ticket is about the removal of MAXWRITETIME function which was added
in CASSANDRA-17425 and firstly introduced in 5.0-alpha1.
This function was identified to be redundant in favor of CASSANDRA-8877 and
CASSANDRA-18060.
The idea of the removal was welcomed and the patch was prepared doing so
but it was never delivered and the question what to do with it, in
connection with 5.0.0, still remains.
The options are:
1) since 18078 was never released in GA, there is still time to remove it.
2) it is too late for the removal hence we would keep it in 5.0.0 and we
would deprecate it in 5.0.1 and remove it in trunk.
It is worth to say that there is a precedent in 2), in CASSANDRA-17495,
where it was the very same scenario. A guardrail was introduced in alpha1.
We decided to release and deprecate in 5.0.1 and remove in trunk. The same
might be applied here, however we would like to have it confirmed if this
is indeed the case or we prefer to just go with 1) and be done with it.
Regards
Re: Suggestions for CASSANDRA-18078
Posted by Yifan Cai <yc...@gmail.com>.
I am voting against this for now.
There is an unaddressed gap between the functions. I do not believe there
is an equivalent replacement for the MAXWRITETIME function already, which
will disrupt its adopters.
MAXWRITETIME handles both single value columns and collections as input.
Meanwhile, COLLECTION_MAX(WRITETIME(..)) only applies to collections. There
is CASSANDRA-18085 aims to extend COLLECTION_MAX to non-collection values.
After merging CASSANDRA-18085, then we have a true replacement and can
remove MAXWRITETIME.
- Yifan
On Thu, Jun 20, 2024 at 10:32 AM Jon Haddad <jo...@jonhaddad.com> wrote:
> Agreed. If we release it, we can’t remove it after. Option 2 is off the
> table.
>
> —
> Jon Haddad
> Rustyrazorblade Consulting
> rustyrazorblade.com
>
>
> On Thu, Jun 20, 2024 at 7:13 PM Jeff Jirsa <jj...@gmail.com> wrote:
>
>> If we have a public-facing API that we’re contemplating releasing to the
>> public, and we don’t think it’s needed, we should remove it before it’s
>> launched and we’re stuck with it forever.
>>
>>
>>
>>
>> On Jun 20, 2024, at 9:55 AM, Jeremiah Jordan <je...@datastax.com>
>> wrote:
>>
>> +1 from me for 1, just remove it now.
>> I think this case is different from CASSANDRA-19556/CASSANDRA-17425. The
>> new guardrail from 19556 which would deprecate the 17425 has not been
>> committed yet. In the case of MAXWRITETIME the replacement is already in
>> the code, we just didn’t remove MAXWRITETIME yet.
>>
>> Jeremiah Jordan
>> e. jeremiah@datastax.com
>> w. www.datastax.com
>>
>>
>>
>> On Jun 20, 2024 at 11:46:08 AM, Štefan Miklošovič <sm...@apache.org>
>> wrote:
>>
>>> List,
>>>
>>> we need your opinions about CASSANDRA-18078.
>>>
>>> That ticket is about the removal of MAXWRITETIME function which was
>>> added in CASSANDRA-17425 and firstly introduced in 5.0-alpha1.
>>>
>>> This function was identified to be redundant in favor of CASSANDRA-8877
>>> and CASSANDRA-18060.
>>>
>>> The idea of the removal was welcomed and the patch was prepared doing so
>>> but it was never delivered and the question what to do with it, in
>>> connection with 5.0.0, still remains.
>>>
>>> The options are:
>>>
>>> 1) since 18078 was never released in GA, there is still time to remove
>>> it.
>>> 2) it is too late for the removal hence we would keep it in 5.0.0 and we
>>> would deprecate it in 5.0.1 and remove it in trunk.
>>>
>>> It is worth to say that there is a precedent in 2), in CASSANDRA-17495,
>>> where it was the very same scenario. A guardrail was introduced in alpha1.
>>> We decided to release and deprecate in 5.0.1 and remove in trunk. The same
>>> might be applied here, however we would like to have it confirmed if this
>>> is indeed the case or we prefer to just go with 1) and be done with it.
>>>
>>> Regards
>>>
>>
>>
Re: Suggestions for CASSANDRA-18078
Posted by Jon Haddad <jo...@jonhaddad.com>.
Agreed. If we release it, we can’t remove it after. Option 2 is off the
table.
—
Jon Haddad
Rustyrazorblade Consulting
rustyrazorblade.com
On Thu, Jun 20, 2024 at 7:13 PM Jeff Jirsa <jj...@gmail.com> wrote:
> If we have a public-facing API that we’re contemplating releasing to the
> public, and we don’t think it’s needed, we should remove it before it’s
> launched and we’re stuck with it forever.
>
>
>
>
> On Jun 20, 2024, at 9:55 AM, Jeremiah Jordan <je...@datastax.com>
> wrote:
>
> +1 from me for 1, just remove it now.
> I think this case is different from CASSANDRA-19556/CASSANDRA-17425. The
> new guardrail from 19556 which would deprecate the 17425 has not been
> committed yet. In the case of MAXWRITETIME the replacement is already in
> the code, we just didn’t remove MAXWRITETIME yet.
>
> Jeremiah Jordan
> e. jeremiah@datastax.com
> w. www.datastax.com
>
>
>
> On Jun 20, 2024 at 11:46:08 AM, Štefan Miklošovič <sm...@apache.org>
> wrote:
>
>> List,
>>
>> we need your opinions about CASSANDRA-18078.
>>
>> That ticket is about the removal of MAXWRITETIME function which was added
>> in CASSANDRA-17425 and firstly introduced in 5.0-alpha1.
>>
>> This function was identified to be redundant in favor of CASSANDRA-8877
>> and CASSANDRA-18060.
>>
>> The idea of the removal was welcomed and the patch was prepared doing so
>> but it was never delivered and the question what to do with it, in
>> connection with 5.0.0, still remains.
>>
>> The options are:
>>
>> 1) since 18078 was never released in GA, there is still time to remove it.
>> 2) it is too late for the removal hence we would keep it in 5.0.0 and we
>> would deprecate it in 5.0.1 and remove it in trunk.
>>
>> It is worth to say that there is a precedent in 2), in CASSANDRA-17495,
>> where it was the very same scenario. A guardrail was introduced in alpha1.
>> We decided to release and deprecate in 5.0.1 and remove in trunk. The same
>> might be applied here, however we would like to have it confirmed if this
>> is indeed the case or we prefer to just go with 1) and be done with it.
>>
>> Regards
>>
>
>
Re: Suggestions for CASSANDRA-18078
Posted by Jeff Jirsa <jj...@gmail.com>.
If we have a public-facing API that we’re contemplating releasing to the public, and we don’t think it’s needed, we should remove it before it’s launched and we’re stuck with it forever.
> On Jun 20, 2024, at 9:55 AM, Jeremiah Jordan <je...@datastax.com> wrote:
>
> +1 from me for 1, just remove it now.
> I think this case is different from CASSANDRA-19556/CASSANDRA-17425. The new guardrail from 19556 which would deprecate the 17425 has not been committed yet. In the case of MAXWRITETIME the replacement is already in the code, we just didn’t remove MAXWRITETIME yet.
>
> Jeremiah Jordan
> e. jeremiah@datastax.com <ma...@datastax.com>
> w. www.datastax.com <http://www.datastax.com/>
>
>
>
> On Jun 20, 2024 at 11:46:08 AM, Štefan Miklošovič <smiklosovic@apache.org <ma...@apache.org>> wrote:
>> List,
>>
>> we need your opinions about CASSANDRA-18078.
>>
>> That ticket is about the removal of MAXWRITETIME function which was added in CASSANDRA-17425 and firstly introduced in 5.0-alpha1.
>>
>> This function was identified to be redundant in favor of CASSANDRA-8877 and CASSANDRA-18060.
>>
>> The idea of the removal was welcomed and the patch was prepared doing so but it was never delivered and the question what to do with it, in connection with 5.0.0, still remains.
>>
>> The options are:
>>
>> 1) since 18078 was never released in GA, there is still time to remove it.
>> 2) it is too late for the removal hence we would keep it in 5.0.0 and we would deprecate it in 5.0.1 and remove it in trunk.
>>
>> It is worth to say that there is a precedent in 2), in CASSANDRA-17495, where it was the very same scenario. A guardrail was introduced in alpha1. We decided to release and deprecate in 5.0.1 and remove in trunk. The same might be applied here, however we would like to have it confirmed if this is indeed the case or we prefer to just go with 1) and be done with it.
>>
>> Regards
Re: Suggestions for CASSANDRA-18078
Posted by Jeremiah Jordan <je...@datastax.com>.
+1 from me for 1, just remove it now.
I think this case is different from CASSANDRA-19556/CASSANDRA-17425. The
new guardrail from 19556 which would deprecate the 17425 has not been
committed yet. In the case of MAXWRITETIME the replacement is already in
the code, we just didn’t remove MAXWRITETIME yet.
Jeremiah Jordan
e. jeremiah@datastax.com
w. www.datastax.com
On Jun 20, 2024 at 11:46:08 AM, Štefan Miklošovič <sm...@apache.org>
wrote:
> List,
>
> we need your opinions about CASSANDRA-18078.
>
> That ticket is about the removal of MAXWRITETIME function which was added
> in CASSANDRA-17425 and firstly introduced in 5.0-alpha1.
>
> This function was identified to be redundant in favor of CASSANDRA-8877
> and CASSANDRA-18060.
>
> The idea of the removal was welcomed and the patch was prepared doing so
> but it was never delivered and the question what to do with it, in
> connection with 5.0.0, still remains.
>
> The options are:
>
> 1) since 18078 was never released in GA, there is still time to remove it.
> 2) it is too late for the removal hence we would keep it in 5.0.0 and we
> would deprecate it in 5.0.1 and remove it in trunk.
>
> It is worth to say that there is a precedent in 2), in CASSANDRA-17495,
> where it was the very same scenario. A guardrail was introduced in alpha1.
> We decided to release and deprecate in 5.0.1 and remove in trunk. The same
> might be applied here, however we would like to have it confirmed if this
> is indeed the case or we prefer to just go with 1) and be done with it.
>
> Regards
>
Re: Suggestions for CASSANDRA-18078
Posted by Mick Semb Wever <mc...@apache.org>.
On Thu, 20 Jun 2024 at 18:46, Štefan Miklošovič <sm...@apache.org>
wrote:
> List,
>
> we need your opinions about CASSANDRA-18078.
>
> That ticket is about the removal of MAXWRITETIME function which was added
> in CASSANDRA-17425 and firstly introduced in 5.0-alpha1.
>
> This function was identified to be redundant in favor of CASSANDRA-8877
> and CASSANDRA-18060.
>
> The idea of the removal was welcomed and the patch was prepared doing so
> but it was never delivered and the question what to do with it, in
> connection with 5.0.0, still remains.
>
> The options are:
>
> 1) since 18078 was never released in GA, there is still time to remove it.
> 2) it is too late for the removal hence we would keep it in 5.0.0 and we
> would deprecate it in 5.0.1 and remove it in trunk.
>
> It is worth to say that there is a precedent in 2), in CASSANDRA-17495,
> where it was the very same scenario. A guardrail was introduced in alpha1.
> We decided to release and deprecate in 5.0.1 and remove in trunk. The same
> might be applied here, however we would like to have it confirmed if this
> is indeed the case or we prefer to just go with 1) and be done with it.
>
Option (2) is my vote.
Rationale: it's our agreed guidelines, we say it hasn't been released but
that's not accurate as we consider betas releases in this context. It's
also the correct approach to take that we shouldn't ever try to avoid. It
should never be a big deal to deal with a deprecate cycle regardless of how
likely we think it isn't needed. I think this is especially true when we
are right at the cusp of cutting 5.0-rc1, and effectively been in rc mode
for a while now. (Yifan's comment hits this point on – not ever rush
something at the last minute.)
But I also have no objections if a waiver to our release lifecycle is
agreed upon. Let common sense prevail – I haven't personally dug into the
issue.
Re: Suggestions for CASSANDRA-18078
Posted by Francisco Guerrero <fr...@apache.org>.
On 2024/06/21 12:00:43 Mick Semb Wever wrote:
> Agreeing with Stefan, Brandon, and Yifan here…
>
Yeah, I agree as well. We want to either have an alternative to MAXWRITETIME
or preserve the existing functionality.
> We are ready to cut 5.0-rc1 and this thread (and any resulting work) is the
> only current blocker.
>
> The argument for leaving things as they are, is…
>
> - MAXWRITETIME as-is is valuable. and is done.
> - We can't mark it deprecated until 18085 lands (ref yifan's point)
> - There is no guarantee that 18085 will ever land (it's already been patch
> ready for 18 months and no one has touched it)
> - The cost of MAXWRITETIME (in addition to 18085) really isn't that high
> (iiuc, it's just a cql keyword)
>
>
> I'd like to rephrase the thread's question.
> Does anyone have an objection to 5.0-rc1 being cut with the code as it is?
> And if so, are they willing to do the work asap that is required and
> blocking 5.0-rc1 ?
No objections to cutting the code as it is.
>
>
>
>
> On Fri, 21 Jun 2024 at 13:22, Štefan Miklošovič <sm...@apache.org>
> wrote:
>
> > I should rather say that tests act as if the application of collection
> > functions to non-collection types would work but that functionality is not
> > in the prod code yet.
> >
> > On Fri, Jun 21, 2024 at 1:17 PM Štefan Miklošovič <sm...@apache.org>
> > wrote:
> >
> >> I do not feel comfortable to rush this.
> >>
> >> For completeness, this is the PR I managed to rebase
> >>
> >> https://github.com/apache/cassandra/pull/3383
> >>
> >> This is CI, bunch of tests are failing
> >>
> >>
> >> https://app.circleci.com/pipelines/github/instaclustr/cassandra/4406/workflows/d46e98e5-e931-41fc-ae51-a7202f3945e3
> >>
> >> Whole WritetimeOrTTLTest fails ...
> >>
> >> I have not investigated what is going on there yet. I think that the PR
> >> already couts with the fact that the application of collection functions to
> >> non-collection types would work but tests are not aligned to that.
> >>
> >>
> >> On Fri, Jun 21, 2024 at 12:41 PM Brandon Williams <dr...@gmail.com>
> >> wrote:
> >>
> >>> Nothing else is blocking the release currently, so unless 18085 is
> >>> ready to commit right now, I don't think it's worth delaying the
> >>> release any further.
> >>>
> >>> Kind Regards,
> >>> Brandon
> >>>
> >>> On Fri, Jun 21, 2024 at 5:32 AM Jon Haddad <jo...@jonhaddad.com> wrote:
> >>> >
> >>> > I’m on vacation, so I’ll keep this brief. While its not the end of
> >>> the world, I think shipping a feature that’s immediately deprecated
> >>> reflects poorly on the project and our ability to manage it.
> >>> >
> >>> > I don’t know how much work need to be done to merge that patch, so its
> >>> hard to say if we should wait for it or if we should ship 5.0 and make an
> >>> exception to add it in 5.0.1. I’d prefer 5.0.1 but i won’t die on this
> >>> hill.
> >>> >
> >>> > Jon
> >>> >
> >>> >
> >>> > On Fri, Jun 21, 2024 at 11:35 AM Mick Semb Wever <mc...@apache.org>
> >>> wrote:
> >>> >>
> >>> >>
> >>> >>
> >>> >> On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe <sa...@beobal.com> wrote:
> >>> >>>
> >>> >>> 100% Option 1. Once it's out in GA release we're stuck with it so
> >>> any short term disruption to adopters of pre-release versions is a trivial
> >>> price to pay.
> >>> >>
> >>> >>
> >>> >>
> >>> >> Sam, Jeremiah, Jeff, Jon,
> >>> >>
> >>> >> we need some clarity on this.
> >>> >>
> >>> >> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes)
> >>> first add CASSANDRA-18085.
> >>> >>
> >>> >> 18085 was slated for 5.x
> >>> >> Are we really going to both a) remove an API that was already
> >>> released in a beta, and b) add in a new improvement into an rc ?
> >>> >>
> >>> >> This is the only remaining issue blocking us from cutting a 5.0-rc1.
> >>> >>
> >>> >>
> >>>
> >>
>
Re: Suggestions for CASSANDRA-18078
Posted by Mick Semb Wever <mc...@apache.org>.
Agreeing with Stefan, Brandon, and Yifan here…
We are ready to cut 5.0-rc1 and this thread (and any resulting work) is the
only current blocker.
The argument for leaving things as they are, is…
- MAXWRITETIME as-is is valuable. and is done.
- We can't mark it deprecated until 18085 lands (ref yifan's point)
- There is no guarantee that 18085 will ever land (it's already been patch
ready for 18 months and no one has touched it)
- The cost of MAXWRITETIME (in addition to 18085) really isn't that high
(iiuc, it's just a cql keyword)
I'd like to rephrase the thread's question.
Does anyone have an objection to 5.0-rc1 being cut with the code as it is?
And if so, are they willing to do the work asap that is required and
blocking 5.0-rc1 ?
On Fri, 21 Jun 2024 at 13:22, Štefan Miklošovič <sm...@apache.org>
wrote:
> I should rather say that tests act as if the application of collection
> functions to non-collection types would work but that functionality is not
> in the prod code yet.
>
> On Fri, Jun 21, 2024 at 1:17 PM Štefan Miklošovič <sm...@apache.org>
> wrote:
>
>> I do not feel comfortable to rush this.
>>
>> For completeness, this is the PR I managed to rebase
>>
>> https://github.com/apache/cassandra/pull/3383
>>
>> This is CI, bunch of tests are failing
>>
>>
>> https://app.circleci.com/pipelines/github/instaclustr/cassandra/4406/workflows/d46e98e5-e931-41fc-ae51-a7202f3945e3
>>
>> Whole WritetimeOrTTLTest fails ...
>>
>> I have not investigated what is going on there yet. I think that the PR
>> already couts with the fact that the application of collection functions to
>> non-collection types would work but tests are not aligned to that.
>>
>>
>> On Fri, Jun 21, 2024 at 12:41 PM Brandon Williams <dr...@gmail.com>
>> wrote:
>>
>>> Nothing else is blocking the release currently, so unless 18085 is
>>> ready to commit right now, I don't think it's worth delaying the
>>> release any further.
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>> On Fri, Jun 21, 2024 at 5:32 AM Jon Haddad <jo...@jonhaddad.com> wrote:
>>> >
>>> > I’m on vacation, so I’ll keep this brief. While its not the end of
>>> the world, I think shipping a feature that’s immediately deprecated
>>> reflects poorly on the project and our ability to manage it.
>>> >
>>> > I don’t know how much work need to be done to merge that patch, so its
>>> hard to say if we should wait for it or if we should ship 5.0 and make an
>>> exception to add it in 5.0.1. I’d prefer 5.0.1 but i won’t die on this
>>> hill.
>>> >
>>> > Jon
>>> >
>>> >
>>> > On Fri, Jun 21, 2024 at 11:35 AM Mick Semb Wever <mc...@apache.org>
>>> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe <sa...@beobal.com> wrote:
>>> >>>
>>> >>> 100% Option 1. Once it's out in GA release we're stuck with it so
>>> any short term disruption to adopters of pre-release versions is a trivial
>>> price to pay.
>>> >>
>>> >>
>>> >>
>>> >> Sam, Jeremiah, Jeff, Jon,
>>> >>
>>> >> we need some clarity on this.
>>> >>
>>> >> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes)
>>> first add CASSANDRA-18085.
>>> >>
>>> >> 18085 was slated for 5.x
>>> >> Are we really going to both a) remove an API that was already
>>> released in a beta, and b) add in a new improvement into an rc ?
>>> >>
>>> >> This is the only remaining issue blocking us from cutting a 5.0-rc1.
>>> >>
>>> >>
>>>
>>
Re: Suggestions for CASSANDRA-18078
Posted by Štefan Miklošovič <sm...@apache.org>.
Third time's a charm.
In order to support that, we would need to include the second commit (1) of
this PR.
I am stuck on (2). Something happened in 5.0 in the meanwhile that this is
not working anymore.
If anybody feels brave enough to fix that, be my guest, I am under the time
pressure with other stuff atm.
(1)
https://github.com/apache/cassandra/pull/2032/commits/877dbdb10585b272e85ece143398d5df9f2089ca
(2)
https://github.com/apache/cassandra/pull/2032/commits/877dbdb10585b272e85ece143398d5df9f2089ca#r1648865085
Regards
On Fri, Jun 21, 2024 at 1:21 PM Štefan Miklošovič <sm...@apache.org>
wrote:
> I should rather say that tests act as if the application of collection
> functions to non-collection types would work but that functionality is not
> in the prod code yet.
>
> On Fri, Jun 21, 2024 at 1:17 PM Štefan Miklošovič <sm...@apache.org>
> wrote:
>
>> I do not feel comfortable to rush this.
>>
>> For completeness, this is the PR I managed to rebase
>>
>> https://github.com/apache/cassandra/pull/3383
>>
>> This is CI, bunch of tests are failing
>>
>>
>> https://app.circleci.com/pipelines/github/instaclustr/cassandra/4406/workflows/d46e98e5-e931-41fc-ae51-a7202f3945e3
>>
>> Whole WritetimeOrTTLTest fails ...
>>
>> I have not investigated what is going on there yet. I think that the PR
>> already couts with the fact that the application of collection functions to
>> non-collection types would work but tests are not aligned to that.
>>
>>
>> On Fri, Jun 21, 2024 at 12:41 PM Brandon Williams <dr...@gmail.com>
>> wrote:
>>
>>> Nothing else is blocking the release currently, so unless 18085 is
>>> ready to commit right now, I don't think it's worth delaying the
>>> release any further.
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>> On Fri, Jun 21, 2024 at 5:32 AM Jon Haddad <jo...@jonhaddad.com> wrote:
>>> >
>>> > I’m on vacation, so I’ll keep this brief. While its not the end of
>>> the world, I think shipping a feature that’s immediately deprecated
>>> reflects poorly on the project and our ability to manage it.
>>> >
>>> > I don’t know how much work need to be done to merge that patch, so its
>>> hard to say if we should wait for it or if we should ship 5.0 and make an
>>> exception to add it in 5.0.1. I’d prefer 5.0.1 but i won’t die on this
>>> hill.
>>> >
>>> > Jon
>>> >
>>> >
>>> > On Fri, Jun 21, 2024 at 11:35 AM Mick Semb Wever <mc...@apache.org>
>>> wrote:
>>> >>
>>> >>
>>> >>
>>> >> On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe <sa...@beobal.com> wrote:
>>> >>>
>>> >>> 100% Option 1. Once it's out in GA release we're stuck with it so
>>> any short term disruption to adopters of pre-release versions is a trivial
>>> price to pay.
>>> >>
>>> >>
>>> >>
>>> >> Sam, Jeremiah, Jeff, Jon,
>>> >>
>>> >> we need some clarity on this.
>>> >>
>>> >> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes)
>>> first add CASSANDRA-18085.
>>> >>
>>> >> 18085 was slated for 5.x
>>> >> Are we really going to both a) remove an API that was already
>>> released in a beta, and b) add in a new improvement into an rc ?
>>> >>
>>> >> This is the only remaining issue blocking us from cutting a 5.0-rc1.
>>> >>
>>> >>
>>>
>>
Re: Suggestions for CASSANDRA-18078
Posted by Štefan Miklošovič <sm...@apache.org>.
I should rather say that tests act as if the application of collection
functions to non-collection types would work but that functionality is not
in the prod code yet.
On Fri, Jun 21, 2024 at 1:17 PM Štefan Miklošovič <sm...@apache.org>
wrote:
> I do not feel comfortable to rush this.
>
> For completeness, this is the PR I managed to rebase
>
> https://github.com/apache/cassandra/pull/3383
>
> This is CI, bunch of tests are failing
>
>
> https://app.circleci.com/pipelines/github/instaclustr/cassandra/4406/workflows/d46e98e5-e931-41fc-ae51-a7202f3945e3
>
> Whole WritetimeOrTTLTest fails ...
>
> I have not investigated what is going on there yet. I think that the PR
> already couts with the fact that the application of collection functions to
> non-collection types would work but tests are not aligned to that.
>
>
> On Fri, Jun 21, 2024 at 12:41 PM Brandon Williams <dr...@gmail.com>
> wrote:
>
>> Nothing else is blocking the release currently, so unless 18085 is
>> ready to commit right now, I don't think it's worth delaying the
>> release any further.
>>
>> Kind Regards,
>> Brandon
>>
>> On Fri, Jun 21, 2024 at 5:32 AM Jon Haddad <jo...@jonhaddad.com> wrote:
>> >
>> > I’m on vacation, so I’ll keep this brief. While its not the end of the
>> world, I think shipping a feature that’s immediately deprecated reflects
>> poorly on the project and our ability to manage it.
>> >
>> > I don’t know how much work need to be done to merge that patch, so its
>> hard to say if we should wait for it or if we should ship 5.0 and make an
>> exception to add it in 5.0.1. I’d prefer 5.0.1 but i won’t die on this
>> hill.
>> >
>> > Jon
>> >
>> >
>> > On Fri, Jun 21, 2024 at 11:35 AM Mick Semb Wever <mc...@apache.org>
>> wrote:
>> >>
>> >>
>> >>
>> >> On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe <sa...@beobal.com> wrote:
>> >>>
>> >>> 100% Option 1. Once it's out in GA release we're stuck with it so any
>> short term disruption to adopters of pre-release versions is a trivial
>> price to pay.
>> >>
>> >>
>> >>
>> >> Sam, Jeremiah, Jeff, Jon,
>> >>
>> >> we need some clarity on this.
>> >>
>> >> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes)
>> first add CASSANDRA-18085.
>> >>
>> >> 18085 was slated for 5.x
>> >> Are we really going to both a) remove an API that was already released
>> in a beta, and b) add in a new improvement into an rc ?
>> >>
>> >> This is the only remaining issue blocking us from cutting a 5.0-rc1.
>> >>
>> >>
>>
>
Re: Suggestions for CASSANDRA-18078
Posted by Štefan Miklošovič <sm...@apache.org>.
I do not feel comfortable to rush this.
For completeness, this is the PR I managed to rebase
https://github.com/apache/cassandra/pull/3383
This is CI, bunch of tests are failing
https://app.circleci.com/pipelines/github/instaclustr/cassandra/4406/workflows/d46e98e5-e931-41fc-ae51-a7202f3945e3
Whole WritetimeOrTTLTest fails ...
I have not investigated what is going on there yet. I think that the PR
already couts with the fact that the application of collection functions to
non-collection types would work but tests are not aligned to that.
On Fri, Jun 21, 2024 at 12:41 PM Brandon Williams <dr...@gmail.com> wrote:
> Nothing else is blocking the release currently, so unless 18085 is
> ready to commit right now, I don't think it's worth delaying the
> release any further.
>
> Kind Regards,
> Brandon
>
> On Fri, Jun 21, 2024 at 5:32 AM Jon Haddad <jo...@jonhaddad.com> wrote:
> >
> > I’m on vacation, so I’ll keep this brief. While its not the end of the
> world, I think shipping a feature that’s immediately deprecated reflects
> poorly on the project and our ability to manage it.
> >
> > I don’t know how much work need to be done to merge that patch, so its
> hard to say if we should wait for it or if we should ship 5.0 and make an
> exception to add it in 5.0.1. I’d prefer 5.0.1 but i won’t die on this
> hill.
> >
> > Jon
> >
> >
> > On Fri, Jun 21, 2024 at 11:35 AM Mick Semb Wever <mc...@apache.org> wrote:
> >>
> >>
> >>
> >> On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe <sa...@beobal.com> wrote:
> >>>
> >>> 100% Option 1. Once it's out in GA release we're stuck with it so any
> short term disruption to adopters of pre-release versions is a trivial
> price to pay.
> >>
> >>
> >>
> >> Sam, Jeremiah, Jeff, Jon,
> >>
> >> we need some clarity on this.
> >>
> >> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes)
> first add CASSANDRA-18085.
> >>
> >> 18085 was slated for 5.x
> >> Are we really going to both a) remove an API that was already released
> in a beta, and b) add in a new improvement into an rc ?
> >>
> >> This is the only remaining issue blocking us from cutting a 5.0-rc1.
> >>
> >>
>
Re: Suggestions for CASSANDRA-18078
Posted by Brandon Williams <dr...@gmail.com>.
Nothing else is blocking the release currently, so unless 18085 is
ready to commit right now, I don't think it's worth delaying the
release any further.
Kind Regards,
Brandon
On Fri, Jun 21, 2024 at 5:32 AM Jon Haddad <jo...@jonhaddad.com> wrote:
>
> I’m on vacation, so I’ll keep this brief. While its not the end of the world, I think shipping a feature that’s immediately deprecated reflects poorly on the project and our ability to manage it.
>
> I don’t know how much work need to be done to merge that patch, so its hard to say if we should wait for it or if we should ship 5.0 and make an exception to add it in 5.0.1. I’d prefer 5.0.1 but i won’t die on this hill.
>
> Jon
>
>
> On Fri, Jun 21, 2024 at 11:35 AM Mick Semb Wever <mc...@apache.org> wrote:
>>
>>
>>
>> On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe <sa...@beobal.com> wrote:
>>>
>>> 100% Option 1. Once it's out in GA release we're stuck with it so any short term disruption to adopters of pre-release versions is a trivial price to pay.
>>
>>
>>
>> Sam, Jeremiah, Jeff, Jon,
>>
>> we need some clarity on this.
>>
>> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes) first add CASSANDRA-18085.
>>
>> 18085 was slated for 5.x
>> Are we really going to both a) remove an API that was already released in a beta, and b) add in a new improvement into an rc ?
>>
>> This is the only remaining issue blocking us from cutting a 5.0-rc1.
>>
>>
Re: Suggestions for CASSANDRA-18078
Posted by Jon Haddad <jo...@jonhaddad.com>.
I’m on vacation, so I’ll keep this brief. While its not the end of the
world, I think shipping a feature that’s immediately deprecated reflects
poorly on the project and our ability to manage it.
I don’t know how much work need to be done to merge that patch, so its hard
to say if we should wait for it or if we should ship 5.0 and make an
exception to add it in 5.0.1. I’d prefer 5.0.1 but i won’t die on this
hill.
Jon
On Fri, Jun 21, 2024 at 11:35 AM Mick Semb Wever <mc...@apache.org> wrote:
>
>
> On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe <sa...@beobal.com> wrote:
>
>> 100% Option 1. Once it's out in GA release we're stuck with it so any
>> short term disruption to adopters of pre-release versions is a trivial
>> price to pay.
>
>
>
> Sam, Jeremiah, Jeff, Jon,
>
> we need some clarity on this.
>
> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes)
> first add CASSANDRA-18085.
>
> 18085 was slated for 5.x
> Are we really going to both a) remove an API that was already released in
> a beta, and b) add in a new improvement into an rc ?
>
> This is the only remaining issue blocking us from cutting a 5.0-rc1.
>
>
>
Re: Suggestions for CASSANDRA-18078
Posted by Mick Semb Wever <mc...@apache.org>.
>
> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes)
> first add CASSANDRA-18085.
>
This statement is inaccurate.
Before 5.0-alpha1 there was no equivalent function for either MAXWRITETIME
or 18085.
Re: Suggestions for CASSANDRA-18078
Posted by Štefan Miklošovič <sm...@apache.org>.
As Mick and Yifan say, we would need to merge CASSANDRA-18085 to fill the
gap. I looked into that and it does not apply cleanly / has some merge
conflicts.
In CASSANDRA-18085, Andres started a thread (1) which gets complicated
pretty fast and honestly I have not read it all yet to give any meaningful
conclusions where to go from there.
(1) https://lists.apache.org/thread/nkm04oo9m60o7dcjzyrll7rzdqzzo1gy
On Fri, Jun 21, 2024 at 11:35 AM Mick Semb Wever <mc...@apache.org> wrote:
>
>
> On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe <sa...@beobal.com> wrote:
>
>> 100% Option 1. Once it's out in GA release we're stuck with it so any
>> short term disruption to adopters of pre-release versions is a trivial
>> price to pay.
>
>
>
> Sam, Jeremiah, Jeff, Jon,
>
> we need some clarity on this.
>
> To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes)
> first add CASSANDRA-18085.
>
> 18085 was slated for 5.x
> Are we really going to both a) remove an API that was already released in
> a beta, and b) add in a new improvement into an rc ?
>
> This is the only remaining issue blocking us from cutting a 5.0-rc1.
>
>
>
Re: Suggestions for CASSANDRA-18078
Posted by Mick Semb Wever <mc...@apache.org>.
On Fri, 21 Jun 2024 at 09:43, Sam Tunnicliffe <sa...@beobal.com> wrote:
> 100% Option 1. Once it's out in GA release we're stuck with it so any
> short term disruption to adopters of pre-release versions is a trivial
> price to pay.
Sam, Jeremiah, Jeff, Jon,
we need some clarity on this.
To remove MAXWRITETIME (CASSANDRA-18078) we must now (as Yifan notes) first
add CASSANDRA-18085.
18085 was slated for 5.x
Are we really going to both a) remove an API that was already released in a
beta, and b) add in a new improvement into an rc ?
This is the only remaining issue blocking us from cutting a 5.0-rc1.
Re: Suggestions for CASSANDRA-18078
Posted by Sam Tunnicliffe <sa...@beobal.com>.
100% Option 1. Once it's out in GA release we're stuck with it so any short term disruption to adopters of pre-release versions is a trivial price to pay.
> On 20 Jun 2024, at 17:46, Štefan Miklošovič <sm...@apache.org> wrote:
>
> List,
>
> we need your opinions about CASSANDRA-18078.
>
> That ticket is about the removal of MAXWRITETIME function which was added in CASSANDRA-17425 and firstly introduced in 5.0-alpha1.
>
> This function was identified to be redundant in favor of CASSANDRA-8877 and CASSANDRA-18060.
>
> The idea of the removal was welcomed and the patch was prepared doing so but it was never delivered and the question what to do with it, in connection with 5.0.0, still remains.
>
> The options are:
>
> 1) since 18078 was never released in GA, there is still time to remove it.
> 2) it is too late for the removal hence we would keep it in 5.0.0 and we would deprecate it in 5.0.1 and remove it in trunk.
>
> It is worth to say that there is a precedent in 2), in CASSANDRA-17495, where it was the very same scenario. A guardrail was introduced in alpha1. We decided to release and deprecate in 5.0.1 and remove in trunk. The same might be applied here, however we would like to have it confirmed if this is indeed the case or we prefer to just go with 1) and be done with it.
>
> Regards