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
