> 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. Also from what I have almost no one tests out -RC's in staging either in the release process, only the release managers/PMC does this. 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 > 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 which may mean maintaining a lot of branches which does add overhead. 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
