Yes, if a method is removed then there must a migration tips been documented. 何品
Matthew de Detrich <matthew.dedetr...@aiven.io.invalid> 于2023年8月4日周五 16:45写道： > > In this thread, I am talking about code with annotations saying they > are deprecated. > > > We have a new issue raised today and it can't proceed until we agree > when it is safe to remove deprecated methods. > > In that case we are in broad agreement and I also agree with kerr's > distinction, i.e. > > > I suggest we remove the deprecated things since Akka 2.5 in pekko 1.1.0 , > and remove those since Akka 2.6.x in pekko 1.2.0. > > With the proviso that there is an alternative to the deprecated method (if > it's > not immediately obvious) and if that's not the case we should properly > document the alternative. > > On Wed, Aug 2, 2023 at 2:21 PM PJ Fanning <fannin...@gmail.com> wrote: > > > In this thread, I am talking about code with annotations saying they > > are deprecated. > > > > We have a new issue raised today and it can't proceed until we agree > > when it is safe to remove deprecated methods. > > > > https://github.com/apache/incubator-pekko/issues/526 > > > > > > On Wed, 2 Aug 2023 at 12:58, Matthew de Detrich > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > Can we be a bit more prescriptive in this discussion thread? i.e. there > > is > > > a big > > > difference between removing some methods which have have been annotated > > > with @deprecated versus entire features such as classic remoting (I > don't > > > think there is any contention about the former). > > > > > > We also need to consider how CVE's change the equation, i.e. I don't > > think > > > it's a good faith argument to tell people to remain on older versions > of > > > Pekko > > > to use features that have known CVE's especially since we spent effort > in > > > delaying the release because of CVE's (there is a bit of lack of > > > consistency here). > > > > > > If we make this distinction between larger features and more trivial > ones > > > I think it's more appropriate to treat those said larger features on a > > case > > > by case basis (i.e. each having their own discussion thread and then a > > > voting round if there is contention). If nothing else this will raise > > > awareness of those features, Pekko is big and we inherited a lot from > > > Akka so I think there is merit in at least having a high level > > understanding > > > of how much code is considered deprecated. > > > > > > On Wed, Aug 2, 2023 at 1:27 PM PJ Fanning <fannin...@apache.org> > wrote: > > > > > > > Hi everyone, > > > > > > > > Tying in with other discussions about what is permissible in the > > > > 'improvements' release of Pekko core. It is tentatively called v1.1.0 > > > > but I suspect that we end up calling it v2.0.0 - if the changes are > > > > big enough. > > > > > > > > I'm going to suggest that we should consider anything that was > > > > deprecated before Akka 2.6.0 as fair game for removal in Pekko > v1.1.0. > > > > > > > > Please feel free to suggest alternatives > > > > > > > > Regards, > > > > PJ > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > -- > > > > > > Matthew de Detrich > > > > > > *Aiven Deutschland GmbH* > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > *m:* +491603708037 > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > -- > > Matthew de Detrich > > *Aiven Deutschland GmbH* > > Immanuelkirchstraße 26, 10405 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > *m:* +491603708037 > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io >
