Re: Removal of deprecations added in Cassandra 3.x
> Personally, I think the removal of the deprecated code which was marked like > that in 3.x is quite safe to do in 5.x but I have to ask broader audience to > have a consensus. Safe for us, sure. Safe for our users, not so much. No amount of including it in release notes guarantees they'll see it, and to Mick's point: > Anything that is public (user-facing) and is isolated code having little cost > to it should just be left. Strong +1 to this sentiment. On Thu, Nov 30, 2023, at 10:33 AM, Mick Semb Wever wrote: >> Personally, I think the removal of the deprecated code which was marked like >> that in 3.x is quite safe to do in 5.x but I have to ask broader audience to >> have a consensus. > > > Strawman: > Evaluate the cost and risk to us by having to keep the code. > Weigh that against the effort it takes for users to adjust their prod > systems, and assume they are many orders of magnitude more than us. > > Anything that is public (user-facing) and is isolated code having little cost > to it should just be left. > >> I think that what is "private" might go away in 5.x easily. > > > Yes. > > >
Re: Removal of deprecations added in Cassandra 3.x
> > Personally, I think the removal of the deprecated code which was marked > like that in 3.x is quite safe to do in 5.x but I have to ask broader > audience to have a consensus. Strawman: Evaluate the cost and risk to us by having to keep the code. Weigh that against the effort it takes for users to adjust their prod systems, and assume they are many orders of magnitude more than us. Anything that is public (user-facing) and is isolated code having little cost to it should just be left. > I think that what is "private" might go away in 5.x easily. > Yes.
Re: Removal of deprecations added in Cassandra 3.x
Hi, I want to refresh this thread. I know people are busy with 5.0 etc. but I would really like to have this resolved. This might be removed in trunk (1). JMX methods / beans to remove are (2) Mick had a point in (1) that even it is possible to remove it all, do we really want to? We should not break things unnecessarily so people do not have hard time to keep up with what we ship, there might be some legacy integrations which might depend on this, even on stuff as old as 3.x. Some custom tooling might call these methods etc. Even it is deprecated, that code is pretty much "maintenance-less". It does not need any special care so we might not look at it as its removal is something critical. Personally, I think the removal of the deprecated code which was marked like that in 3.x is quite safe to do in 5.x but I have to ask broader audience to have a consensus. We might be extra careful and drop it in 6.0 instead of 5.x so I would have to wait for 6.0 branch to be created. Supporting deprecated code for 2 majors sounds pretty safe to me. This is all written for cases when the code is public-facing - JMX methods etc. I think that what is "private" might go away in 5.x easily. Anyway, It is a good question was is considered to be a public API, I think that Josh was talking about this in some other thread already. I would like to start to map the codebase and annotate interfaces / extension points etc with something like "@PublicApi" or even "@Stable" / "@Unstable" and similar so we can reason about what is public or not more explicitly but this is not the topic I want to go into here. (1) https://issues.apache.org/jira/browse/CASSANDRA-18975 (2) https://github.com/apache/cassandra/pull/2853/files#diff-4e5b9f6d0d76ab9ace1bd805efe5788bb5d23c84c25ccf75b9896f20b46a1879 Thanks and regards From: Miklosovic, Stefan via dev Sent: Monday, October 30, 2023 23:07 To: dev@cassandra.apache.org Cc: Miklosovic, Stefan Subject: Re: Removal of deprecations added in Cassandra 3.x NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. Sure we can do that just for trunk. No problem with that. Hence, I am parking this effort for a while. From: Mick Semb Wever Sent: Monday, October 30, 2023 22:56 To: dev@cassandra.apache.org Subject: Re: Removal of deprecations added in Cassandra 3.x NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. > similarly as for Cassandra 1.x and 2.x deprecations removal done in > CASSANDRA-18959, you are welcome to comment on the removal of all stuff > deprecated in 3.x (1). > > If nobody objects after couple days I would like to proceed to the actual > removal. Please tell me if you want something to keep around. > I have concerns, but I won't block. I would like to propose we focus on getting to a 5.0-beta1 release. To do that we should be stopping all work on cassandra-5.0 that isn't about stabilisation. Can this land in trunk instead ? How much work is in front of us to get to 5.0-beta1 ? (Please add fixVersion 5.0-beta for stabilisation work.)
Re: Removal of deprecations added in Cassandra 3.x
Sure we can do that just for trunk. No problem with that. Hence, I am parking this effort for a while. From: Mick Semb Wever Sent: Monday, October 30, 2023 22:56 To: dev@cassandra.apache.org Subject: Re: Removal of deprecations added in Cassandra 3.x NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe. > similarly as for Cassandra 1.x and 2.x deprecations removal done in > CASSANDRA-18959, you are welcome to comment on the removal of all stuff > deprecated in 3.x (1). > > If nobody objects after couple days I would like to proceed to the actual > removal. Please tell me if you want something to keep around. > I have concerns, but I won't block. I would like to propose we focus on getting to a 5.0-beta1 release. To do that we should be stopping all work on cassandra-5.0 that isn't about stabilisation. Can this land in trunk instead ? How much work is in front of us to get to 5.0-beta1 ? (Please add fixVersion 5.0-beta for stabilisation work.)
Re: Removal of deprecations added in Cassandra 3.x
> similarly as for Cassandra 1.x and 2.x deprecations removal done in > CASSANDRA-18959, you are welcome to comment on the removal of all stuff > deprecated in 3.x (1). > > If nobody objects after couple days I would like to proceed to the actual > removal. Please tell me if you want something to keep around. > I have concerns, but I won't block. I would like to propose we focus on getting to a 5.0-beta1 release. To do that we should be stopping all work on cassandra-5.0 that isn't about stabilisation. Can this land in trunk instead ? How much work is in front of us to get to 5.0-beta1 ? (Please add fixVersion 5.0-beta for stabilisation work.)
Removal of deprecations added in Cassandra 3.x
Hi, similarly as for Cassandra 1.x and 2.x deprecations removal done in CASSANDRA-18959, you are welcome to comment on the removal of all stuff deprecated in 3.x (1). If nobody objects after couple days I would like to proceed to the actual removal. Please tell me if you want something to keep around. (1) https://issues.apache.org/jira/browse/CASSANDRA-18975 Thanks
