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 > >
