The two minor versions deprecation rule is something we could change pretty easily, and that’s probably the biggest difference from semver. The other differences are more specific to akka/pekko, e.g., no mixed versioning and specific APIs/modules that may change. So maybe we’re comfortable using VersionScheme.SemVerSpec if we just agree to only remove deprecated APIs in major versions. I still think we can treat the Akka deprecations as an exception here though.
On Tue, Aug 8, 2023 at 03:05 Matthew de Detrich <[email protected]> wrote: > > 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 <[email protected]> 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 > > <[email protected]> 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 <[email protected]> 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 > > > > <[email protected]> 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 <[email protected]> > > 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 <[email protected]> > > > 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 > > > > > > > <[email protected]> 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 < > > [email protected] > > > > > > > > > > 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 > > > > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > > > > > > > On Fri, Aug 4, 2023 at 9:48 AM kerr <[email protected] > > > > > > 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: [email protected] > > > > > > > > > > For additional commands, e-mail: > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > 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:* [email protected] > > > > > > > > > > > > > > > > > > -- > > > > > > 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:* [email protected] > > > > > > > > -- > > 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:* [email protected] >
