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
