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 <dev@cassandra.apache.org> 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 <m...@apache.org> 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.)
