> Technically it's a little different because @ApiMayChange is technically part of the public API but we'd have to say it's not public API only for the purposes of semver, while the others are considered internal API. Semver doesn't have the concept of an API that is public but may change.
Yeah I think we are scraping the bottom of the barrel a bit here. Ultimately if we say that @ApiMayChange is not part of semver guarantees thats thats perfectly reasonable and practical (regardless if we decide to use semver or not) > Anyway I really don't want to derail the discussion here. I would be fine with PJ's original proposal of removing anything that was deprecated before Akka 2.6 in Pekko 1.1, then in 1.2 we can remove the stuff deprecated in Akka 2.6.x. We could treat this all as a special case for Akka compatibility, and then going forward follow some other approach for deprecations we decide on later. >From my side its more that if we are specifying VersionScheme.SemVerSpec we should really follow it otherwise its misleading, and as stated before its not just some descriptor metadata field in POM, sbt actually reads this field when doing dependency resolution so it has a meaningful impact. As I said before I regret adding this in there, I wasn't really thinking about it at the time and completely forgot that Akka had its own derivation of semver which technically wasn't semver (not talking about trivial issues like @ApiMayChange but rather more fundamental points such as deprecation which we are talking about now). I think if we are going to follow Akka's versioning scheme we should remove the field (or even better submit this VersionScheme to sbt so it can actually enforce it). Thankfully VersionScheme.SemVerSpec is only set for 1.0.x of Pekko and its module and maybe having VersionScheme.SemVerSpec for only that series makes sense, we really do not want to break anything for the 1.0.x series since its a transition version from Akka. On Mon, Aug 7, 2023 at 2:49 PM Greg Methvin <gr...@apache.org> wrote: > > Well the easy way to handle the @ApiMayChange is to just state that > > its not part of semantic versioning, just like > > private/package-private/@InternalStableAPI > > Technically it's a little different because @ApiMayChange is technically > part of the public API but we'd have to say it's not public API only for > the purposes of semver, while the others are considered internal API. > Semver doesn't have the concept of an API that is public but may change. > > Anyway I really don't want to derail the discussion here. I would be fine > with PJ's original proposal of removing anything that was deprecated before > Akka 2.6 in Pekko 1.1, then in 1.2 we can remove the stuff deprecated in > Akka 2.6.x. We could treat this all as a special case for Akka > compatibility, and then going forward follow some other approach for > deprecations we decide on later. > > On Mon, Aug 7, 2023 at 4:58 AM Matthew de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > That's very surprising to me. IMO the documentation should be the > source > > of > > truth here. We are still using markers like @ApiMayChange which are > > incompatible with strict semver, and (I think) we still want to forbid > > mixed versioning. > > > > Well the easy way to handle the @ApiMayChange is to just state that > > its not part of semantic versioning, just like > > private/package-private/@InternalStableAPI > > is. Also in case people are not aware, if we set > VersionScheme.SemVerSpec, > > this > > just instructs how sbt will warn about dependencies when you do > dependency > > resolution, > > i.e. if you in your build you have Pekko 1.0.x being resolved by one > > transitive dependency > > and Pekko 2.0.x being resolved by another transitive dependency then if > you > > have VersionScheme.SemVerSpec set, sbt by default will warn prevent the > > build from loading > > because you have changes that break semver (this btw can be overridden). > > > > Also I am not saying that we shouldn't change this, just that there was > > likey > > misconception about whether Pekko would move to semver or not and this > > should > > be discussed. > > > > On Mon, Aug 7, 2023 at 1:44 PM Greg Methvin <gr...@apache.org> wrote: > > > > > That's very surprising to me. IMO the documentation should be the > source > > of > > > truth here. We are still using markers like @ApiMayChange which are > > > incompatible with strict semver, and (I think) we still want to forbid > > > mixed versioning. To me the sbt setting is just configuring what kinds > of > > > compatibility issues sbt will catch, beyond that it's up to the user > (as > > it > > > always has been in Akka). > > > > > > > > > > > > On Mon, Aug 7, 2023 at 4:10 AM Matthew de Detrich > > > <matthew.dedetr...@aiven.io.invalid> 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. > > > > > > > > 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 > > > > > > > > > > > > > -- > > > > 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 > > > -- 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
