> 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.
Pekko does use strict semantic versioning since it is set in sbt https://github.com/apache/incubator-pekko/blob/main/build.sbt#L17 and since it is set that way sbt users will get problems if we don't follow it strictly > 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". We probably should revisit this documentation and/or what our expectations are for Pekko. I think it's regrettable that we didn't talk about this in the past but we should have voted/clarified if we wanted to keep Akka's compatibility vs semver. On Mon, Aug 7, 2023 at 12:43 PM Greg Methvin <gr...@apache.org> wrote: > 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 > > > > > -- 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
