I am a bit confused by the starting point of this discussion: "When we
deprecate APIs / methods"
What are we exactly calling APIs/methods? It is really unclear to me what
we are talking about here.
Le jeu. 12 oct. 2023 à 02:38, Francisco Guerrero a
écrit :
>
>
> On 2023/10/11 16:59:35 Maxim Muza
Hi Benjamin,
in other words, anything we have @Deprecated annotation on top of (or anything
you want to annotate with it). Does it help with the explanation?
For the initial phase, I plan to just put "since" everywhere (into every
already existing @Deprecated annotation) and we leave out "forRe
I was asking because outside of configuration parameters and JMX calls, the
approach as far as I remember was to just change things without using an
annotation.
Le ven. 13 oct. 2023 à 12:45, Miklosovic, Stefan via dev <
dev@cassandra.apache.org> a écrit :
> Hi Benjamin,
>
> in other words, anythi
OK. That is definitely something to mention when we will approach the second
phase where we decide what do with it but I humbly think we are not there yet.
Could you point me some document / ML thread this was explicitly decided in if
you know of anything like that? It would be great if there w
On Fri, 13 Oct 2023 at 13:07, Benjamin Lerer wrote:
> I was asking because outside of configuration parameters and JMX calls,
> the approach as far as I remember was to just change things without using
> an annotation.
>
Yes, it is my understanding that such deprecation is only needed on
method
>
> Could you point me some document / ML thread this was explicitly decided
> in if you know of anything like that? It would be great if there was some
> solid guidance on this.
I am seeing it the other way around. Using Deprecated annotations make
sense only if something is part of a public int
I’ve been told in the past not to remove public methods in a patch release
though.
On Fri, 13 Oct 2023 at 8:03, Benjamin Lerer wrote:
> Could you point me some document / ML thread this was explicitly decided
>> in if you know of anything like that? It would be great if there was some
>> solid g
Maybe for better understanding what we talk about, there is the PR which
implements the changes suggested here (1)
It is clear that @Deprecated is not used exclusively on JMX / Configuration but
we use it internally as well. This is a very delicate topic and we need to go,
basically, one by one
>
> I’ve been told in the past not to remove public methods in a patch release
> though.
>
Then I am curious to get the rationale behind that. If some piece of code
is not used anymore then simplifying the code is the best thing to do. It
makes maintenance easier and avoids mistakes.
Le ven. 13 oc
Ok, thanks Stefan I understand the context better now. Looking at the PR.
Some make sense also for serialization reasons but some make no sense to me.
Le ven. 13 oct. 2023 à 14:26, Benjamin Lerer a écrit :
> I’ve been told in the past not to remove public methods in a patch release
>> though.
>
I think the source code can describe the intention better than words :-)
The link to our Code Style with a discussion "summary":
https://github.com/apache/cassandra-website/pull/245/files
The link to the pull request with the proposed changes (only "since"
added and description):
https://github.c
OK. So here we are ... round 1 will be to map how bad it is, round 2 will be
the removal of what should not be there. I am not sure if round 2 will be done
before 5.0 is out (that would be ideal, to release 5.0 without a lot of baggage
like that) so it will be better if we split this effort into
I forgot the round #3.
That would consist of an ant task which would scan the source. Since we
enforced that each Deprecation annotation has to have its "since" on compile
time, we can write a parser in that task which would tell you what you have to
do in order to be sure that your next releas
> If some piece of code is not used anymore then simplifying the code is the
> best thing to do
In the case of unused / unreferenced, sure. In the case of "other things use
this but we shouldn't add any more dependencies on this because we need to
remove it", a @Deprecated annotation w/version,
How I look at it is that if we clearly and explicitly specify "since" and
"forRemoval" for all of our @Deprecated annotations, then it does really matter
who is the consumer of that?
Imagine a scenario where there is some tool which puts cassandra-all on the
class path and then it cherry-picks
15 matches
Mail list logo
