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
