> 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
