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
