This release is blocked by this: https://github.com/apache/pekko/discussions/1233
We may not be adding additional API methods but it seems likely that we will change the way that the deletion of durable state objects works. On 2024/03/26 08:59:16 Matthew de Detrich wrote: > > This does not care about source compatibility, and allows behavioural > and dependency changes to a large extent (as long as X doesn't rely on > specific behaviour of Y or its dependencies). While we use MiMa to check > we don't accidentally introduce binary incompatibilities, not every change > that gets flagged by MiMa is in fact problematic: indeed, modules marked > ApiMayChange or InternalApi are fine to change, as they shouldn't be > relied on by other libraries. > > This I am aware but specifically in the case of Slick, iirc the > changes that MiMa > complained about from Slick 3.3.x to 3.3.5 were of concern and not false > alarms and it wasn't just in the ApiMayChange/InternalApi, i.e. > https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes#L25-L34 > is a public class > > > Do we have any obligation to maintain old branches? I'm not sure we should. > > This is something we still need to discuss, its just to be aware of. It > becomes > increasingly concerning if underlying critical libraries constantly > break ABI and users > of those libraries can't always update to the latest version of that > underlying library > (which is understandable). The most extreme example of this is > pekko-connectors, > if we applied semver there we would have something ridiculous like 10 > major version > bumps in a year which is why we are exploring splitting out the > various connectors in > their own modules since some rarely update in a breaking way and some update > frequently in a breaking way. > > > I'd say the core question is: could I use Pekko Projection 1.0.0 with the > to-be-released Pekko Persistence JDBC? If so, I'm in favor of releasing > as 1.1.0-M1 (or 1.1.0, no strong preference). If not, I think we should > consider releasing it as 2.0.0-M1 (or 2.0.0, no strong preference). > > Given what I said about MiMa earlier, if I am correct then the answer is no > in which case it should be 2.0.0-M1/2.0.0 and I should add back in the > sbt SemVer versionScheme. > > Others wdyt? > > On Tue, Mar 26, 2024 at 9:48 AM Arnout Engelen <enge...@apache.org> wrote: > > > > On Tue, Mar 26, 2024 at 9:16 AM Matthew de Detrich > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > If I understand correctly we want to create this M1 because we don't > > > > feel > > > the code is well-tested enough to warrant a 1.1.0? Are people more likely > > > to try an M1 than they are to try the snapshots from > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/ > > > ? Should they be? > > > > > > In my opinion, most definitely yes. Almost no one uses snapshots > > > unless they are eager to try > > > a new feature that they are personally waiting for. > > > > > > Right - wouldn't Slick 3.5 support be such a feature? > > > > > > > Is this ideal? No. I think that largely this is probably a result of > > > ASF process being foreign to > > > a lot of Scala users/OS projects so its something that should get > > > better over time but aside from > > > that there are legitimate concerns that the changes in Slick 3.5.x are > > > so big that an -M1 is > > > warranted. As stated before when Slick 3.5.0-RC1 came out, because we > > > have a policy > > > of always needing the current state of release branches + main to be > > > in a releasable state we > > > couldn't deliver a snapshot/milestone/RC etc etc of our own that users > > > could test to make sure > > > that Slick 3.5.x could work > > > > > > > We could (and did) as soon as Slick 3.5.0 came out, though, right? > > > > > This release contains a number of binary-incompatible changes that were > > > excluded from MiMa[1]. In the future, it would be really helpful to > > > document in the exclusion file why these exclusions are warranted. I > > > understand from [2] that these changes don't "really affect the user > > > facing > > > APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'. > > > It'd be good to more consistently mark things 'ApiMayChange' (or > > > 'InternalApi') in the future. > > > > > > So I actually want to remove SemVer from this module precisely because > > > we are expecting > > > to break it so many times. Then again, we can just leave in SemVer and > > > bump the major, > > > I am not that picky about this but I guess looking forward the main > > > reason to not subscribe > > > to SemVer for the jdbc module specifically is to not have to deal with > > > large number of > > > major version bumps which can be a risk given Slick's history of > > > breakages (same deal > > > with gRPC). > > > > > > Still, in [3] we do call this a 'breaking update' that will impact > > > pekko-projection. What does this breakage look like? By what criterium > > > (existing or to be formulated) is this breakage in a category that is > > > exempt from requiring a major version bump? > > > > > > So yes it is a breaking update, both in terms of MiMA and in source > > > code as well. This is > > > due to the Slick 3.3.x to 3.5.x update. If we think its more > > > appropriate to stick to SemVer and > > > just bump the major I am happy with that, we just open ourselves to > > > risk of having lots of major > > > version bumps in the future > > > > > > Regardless of whether we do SemVer, I think we should be somewhat > > explicit about what kinds of changes should happen in a major version > > bump. > > > > Personally I find SemVer overly strict in that I'm fine with adding features > > in a backwards-compatible way in a patch version, but I don't feel too > > strongly about this. > > > > I do think the binary compatibility rules[0] are still sensible. The > > intuition > > behind those rules is: if you're depending on library X which depends on > > pekko module version Y, you should generally be able to upgrade Y within > > minor versions without also upgrading X. This is extremely helpful as it > > means updates of Y don't force a release of X, which saves a lot of work > > releasing. > > > > This does not care about source compatibility, and allows behavioural > > and dependency changes to a large extent (as long as X doesn't rely on > > specific behaviour of Y or its dependencies). While we use MiMa to check > > we don't accidentally introduce binary incompatibilities, not every change > > that gets flagged by MiMa is in fact problematic: indeed, modules marked > > ApiMayChange or InternalApi are fine to change, as they shouldn't be > > relied on by other libraries. > > > > I'd say the core question is: could I use Pekko Projection 1.0.0 with the > > to-be-released Pekko Persistence JDBC? If so, I'm in favor of releasing > > as 1.1.0-M1 (or 1.1.0, no strong preference). If not, I think we should > > consider releasing as 2.0.0-M1 (or 2.0.0, no strong preference). > > > > [0]: > > https://pekko.apache.org/docs/pekko/current/common/binary-compatibility-rules.html > > > > > > > which may mean maintaining a lot of > > > branches which does add overhead. > > > > > > > Do we have any obligation to maintain old branches? I'm not sure we should. > > > > > > Kind regards, > > > > Arnout > > > > > > > On Mon, Mar 25, 2024 at 4:46 PM Arnout Engelen <enge...@apache.org> wrote: > > > > > > > > 1) 1.1.0 or 1.1.0-M1? > > > > > > > > I, too, am somewhat wary of the confusion introduced by creating > > > > 'milestone' releases for various reasons. > > > > > > > > If I understand correctly we want to create this M1 because we don't > > > > feel > > > > the code is well-tested enough to warrant a 1.1.0? Are people more > > > > likely > > > > to try an M1 than they are to try the snapshots from > > > > > > > https://repository.apache.org/content/groups/snapshots/org/apache/pekko/pekko-persistence-jdbc_3/ > > > > ? Should they be? > > > > > > > > I can sort of see this being a 'chicken and egg' problem and am not > > > opposed > > > > to releasing it as M1. In the future I hope we can get enough testing > > > > through the snapshots and not need such 'milestone' releases anymore, > > > > though. > > > > > > > > 2) 1.1.0-M1 or 2.0.0-M1? > > > > > > > > This release contains a number of binary-incompatible changes that were > > > > excluded from MiMa[1]. In the future, it would be really helpful to > > > > document in the exclusion file why these exclusions are warranted. I > > > > understand from [2] that these changes don't "really affect the user > > > facing > > > > APIs". Looking at a few classes, indeed some are marked 'ApiMayChange'. > > > > It'd be good to more consistently mark things 'ApiMayChange' (or > > > > 'InternalApi') in the future. > > > > > > > > Still, in [3] we do call this a 'breaking update' that will impact > > > > pekko-projection. What does this breakage look like? By what criterium > > > > (existing or to be formulated) is this breakage in a category that is > > > > exempt from requiring a major version bump? > > > > > > > > [1]: > > > > > > > https://github.com/apache/pekko-persistence-jdbc/blob/main/core/src/main/mima-filters/1.1.x.backwards.excludes/slick-3.3-to-3.5.backwards.excludes > > > > [2]: https://lists.apache.org/thread/olb2gt0sojogxjfy2y09cs26ty8lqbw3 > > > > [3]: https://lists.apache.org/thread/k75dj2p8cfjhjzf6go2pod6y3tsg71j7 > > > > > > > > On Thu, Mar 7, 2024 at 4:02 PM Matthew de Detrich > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > I would favour just making a full 1.1.0 release. I don't see the > > > > > benefit of having a milestone release. > > > > > > > > > > It was requested for us to do an RC so the community could properly > > > test > > > > > Slick 3.5.0-RC5 but we didn't do this because we want our projects to > > > > > always be in a releasable state[1] and hence I suspect that no one > > > really > > > > > tested > > > > > pekko-persistence-jdbc because it wasn't really announced anywhere. > > > > > The > > > > > changes from Slick 3.3.x to 3.5.0 were extremely extensive so I think > > > it's > > > > > warranted > > > > > to be more prudent here. > > > > > > > > > > Also we need to make sure that the project works properly with > > > pekko-core > > > > > 1.1.x > > > > > along with all of the inlining and other changes and pekko-core 1.1.x > > > > > hasn't > > > > > even been released yet. > > > > > > > > > > Support for the latest oracle[2] is also something that we may want to > > > add > > > > > after M1, > > > > > this seems to be undecided? > > > > > > > > > > 1: > > > > > > > > https://github.com/slick/slick/discussions/2891#discussioncomment-8550269 > > > > > 2: https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115 > > > > > > > > > > On Thu, Mar 7, 2024 at 3:53 PM PJ Fanning <fannin...@gmail.com> wrote: > > > > > > > > > > > I would favour just making a full 1.1.0 release. I don't see the > > > > > > benefit of having a milestone release. > > > > > > > > > > > > On Thu, 7 Mar 2024 at 15:14, Matthew de Detrich > > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > > > Now that Scala 3 support has been merged with the release of > > > > > > > Slick 3.5.0[1] I think it's a good time to make a M1 release given > > > that > > > > > > > the changes in Slick 3.5.0 were so extensive, just to make sure > > > > > > everything > > > > > > > is working as intended and a milestone release should signal to > > > > > > > the > > > > > > > community to "please use it to test it". > > > > > > > > > > > > > > Since scala steward support is merged[2] doing the milestone when > > > > > > > the update PR's are created early next week seems like a good > > > candidate > > > > > > > in terms of time. There also is a question of whether we should > > > also > > > > > > > fix the issue with the latest oracle version[2] for the M1. > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > 1: > > > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/44 > > > > > > > 2: > > > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/123 > > > > > > > 3: > > > https://github.com/apache/incubator-pekko-persistence-jdbc/pull/115 > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > > > Alexanderufer 3-7, 10117 Berlin > > > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > 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 > > > > > > > > > > Alexanderufer 3-7, 10117 Berlin > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > > > > > -- > > > > Arnout Engelen > > > > ASF Security Response > > > > Apache Pekko PMC member, ASF Member > > > > NixOS Committer > > > > Independent Open Source consultant > > > > > > > > > > > > -- > > > > > > Matthew de Detrich > > > > > > Aiven Deutschland GmbH > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > Alexanderufer 3-7, 10117 Berlin > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > m: +491603708037 > > > > > > w: aiven.io e: matthew.dedetr...@aiven.io > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > -- > > Arnout Engelen > > ASF Security Response > > Apache Pekko PMC member, ASF Member > > NixOS Committer > > Independent Open Source consultant > > > > -- > > Matthew de Detrich > > Aiven Deutschland GmbH > > Immanuelkirchstraße 26, 10405 Berlin > > Alexanderufer 3-7, 10117 Berlin > > Amtsgericht Charlottenburg, HRB 209739 B > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > m: +491603708037 > > w: aiven.io e: matthew.dedetr...@aiven.io > > --------------------------------------------------------------------- > 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
