If we consider Pekko 1.0 as equivalent to Akka 2.6 (which I think is reasonable), that would mean, per Akka's existing deprecation rules, that in Pekko 1.1 we could remove anything deprecated in Akka 2.5, and in Pekko 1.2 we could remove anything deprecated in Akka 2.6. I think that's pretty reasonable actually.
I would reserve Pekko 2.0 for when we want to truly take Pekko in a new direction and make major API changes, not just remove things that were already deprecated in Akka. On Mon, Aug 7, 2023 at 3:41 AM Nicolas Vollmar <nvoll...@gmail.com> wrote: > Pekko 1.0 is probably perceived as roughly equivalent to Akka 2.6 for the > sake of migration. > The 2.0 would make it more obvious as the next step of Pekko going its own > direction. > > I'd also consider 1.0 a major release since just by the fact that it is > neither source nor binary compatible and as a grace period before moving > away. > > If we only drop the code level deprecations, 1.1 would be perfectly fine > IMO. > If we're going to drop whole features like classic remoting or JDK8 I'd > tend for a 2.0 release. > > On Mon, 7 Aug 2023 at 12:29, PJ Fanning <fannin...@gmail.com> wrote: > > > Pekko is not Akka. We branched off Akka 2.6. There is a strong > > argument that Pekko 1.0 is like an Akka 3 release from a semver > > perspective. > > > > This means that anything that is deprecated in Akka 2 can be removed in > > Pekko. > > > > If we want to pretend that Pekko 1.0 is basically equivalent to Akka > > 2.7 - then there is maybe an argument that we can't remove any code > > deprecated in Akka 2.x. > > > > The thing is Akka didn't/doesn't follow the concept that deprecated > > can only be removed in a major release. They appear to have allowed > > deprecated code to be removed after a few minor releases. I don't > > think this approach is uncommon but I'm happy enough for Pekko not to > > follow this going forward and to only remove deprecated code in a > > major release. > > > > I'm still going to argue that Pekko 1.0 is a major release. To ease > > transition of Akka users, we didn't remove deprecated code in Pekko > > 1.0. That does not stop us from removing any code that was deprecated > > in Akka in Pekko 1.1. > > > > In the end of the day, I don't really mind if we don't bother with a > > Pekko 1.1 release and that we call the next non-1.0 release Pekko 2.0. > > > > On Mon, 7 Aug 2023 at 06:52, Claude Warren, Jr > > <claude.war...@aiven.io.invalid> wrote: > > > > > > Based on semantic numbering. You may only relemove deprecated code on > a > > > major version change. Anything else is a breaking change. If you mark > > > something as deprecated you are noting a change in the contract with > the > > > user, thus a breaking change. > > > > > > On Fri, Aug 4, 2023 at 12:17 PM PJ Fanning <fannin...@apache.org> > wrote: > > > > > > > With the Apache release process and the fact that as an incubating > > > > project, that we need 2 phase approval on all releases - a Pekko > 1.1.0 > > > > release and a subsequent release of all the downstream Pekko modules > > > > to uptake Pekko 1.1.0 will take months. We are less than halfway > > > > through the Pekko 1.0.0 releases and we started those weeks ago. > > > > > > > > So, for me, that means that we shouldn't really be thinking about > > > > small iterations. I can live with the idea of a Pekko 1.1.0 release > > > > but the idea that we would make a few small changes in Pekko 1.1.0 > and > > > > then think we can then move on quickly to a Pekko 1.2.0 release - > that > > > > doesn't work for me. There is so much release overhead and test > > > > overhead with those releases, that we should be thinking about > > > > something in the magnitude of a year between non-patch releases. > > > > > > > > I can see that Pekko 1.1.0 could be released in 3 to 6 months because > > > > there is probably some pent up demand to change what was in Akka 2.6 > > > > (which as Johannes points out is quite old already). But for me, > Pekko > > > > 1.2.0 should be seen as something that wouldn't be released for a > year > > > > or so after Pekko 1.1.0 goes out. > > > > > > > > On Fri, 4 Aug 2023 at 10:54, Johannes Rudolph > > > > <johannes.rudo...@gmail.com> wrote: > > > > > > > > > > On Fri, Aug 4, 2023 at 9:48 AM kerr <hepin1...@gmail.com> wrote: > > > > > > 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. > > > > > > > > > > I'm for more aggressive removal. Many things have been deprecated > for > > > > > many years (2.6.0 is almost 4 years ago) and with Pekko 1.0.x we > give > > > > > everyone another a free release keep using deprecated methods. > > > > > > > > > > After all, with Pekko 1.0.x out, it will be easy enough for users / > > > > > companies to engage in the 1.0.x maintenance process to keep it > going > > > > > forever if necessary. > > > > > > > > > > Going forward, we should remove what we can for 1.1/2.0. Of course, > > > > > this will make it a bit harder for people to adopt a potential new > > > > > version, but this is not a one-way track where the OS developers > have > > > > > to pay all the cost of maintaining old code while users get free > > > > > updates. > > > > > > > > > > And to be clear I'm not advocating for going quick and breaking > > things > > > > > but as it stands we have to cut down on something to make progress. > > As > > > > > I see it the value proposition for the different versions is this: > > > > > > > > > > * Pekko 1.0: give users an 1.) upgrade path that is as smooth as > > > > > possible 2.) set up the infrastructure to maintain that version > for a > > > > > longer time (in case there's sufficient community to keep it > running) > > > > > * Pekko 1.1/2.0: evolve the codebase carefully and eventually > > provide > > > > > new enhancements / features that make it attractive enough to > > eventual > > > > > move over > > > > > > > > > > Johannes > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > >
