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 <jerem...@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. jerem...@datastax.com <mailto:jerem...@datastax.com> > w. www.datastax.com <http://www.datastax.com/> > > > > On Jun 20, 2024 at 11:46:08 AM, Štefan Miklošovič <smikloso...@apache.org > <mailto:smikloso...@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
