Pekko doesn’t use semantic versioning, at least not in any strict sense. Maybe in the future we should move closer to real semver, but that's a different discussion. Our binary compatibility rules [1] have a number of differences from semver, and specifically allow us to remove deprecated methods after two full minor releases [2]. These rules are essentially the same as Akka's, though we also added a note that "methods that were deprecated in Akka, before the project fork to Pekko, are being considered for removal in Pekko 1.1.0".
[1] https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html [2] https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html#when-will-a-deprecated-method-be-removed-entirely On Mon, Aug 7, 2023 at 3:29 AM 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 > >
