apache
Set `currentVersion` in `PekkoCoreDependency` to `1.1.0-M1` once M1 is released
As stated in https://github.com/apache/incubator-pekko/pull/857 specifically
It may be that for the Pekko module 1.1.x series they will have to build against Pekko core 1.1.x because while the
@inlineannotations existed in Pekko 1.0.x, theinlinekeyword for Scala 3 in various places was only added in Scala 3. This however shouldn't cause any issues because a Pekko module built against Pekko core 1.1.x would inline all relevant code, so even if a Pekko core 1.0.x is linked at runtime in a Pekko 1.1.x module, all it means is that the Pekko 1.0.x will bring in some unused code.
Note that this will not have any effect if you use Pekko Http 1.1.x against Pekko Core 1.0.x, i.e. a Pekko Http built with Pekko Core 1.1.x will still work if you link against Pekko Core 1.0.x at runtime, I have already tested this. We also have nightly builds that confirm this.
Goes without saying that this will only be the case for Pekko 1.1.x or higher, i.e. the Pekko 1.0.x branches will not have this change.
If we are going to build Pekko HTTP 1.1.x against Pekko 1.1.x then we need to look at creating integration tests that use Pekko HTTP jars but that test with Pekko 1.0.x. We want to have Pekko HTTP 1.1.x support Pekko 1.0.x. If we decide not to do this, then we need a team decision to abandon Pekko 1.0.x compatibility.
If we are going to build Pekko HTTP 1.1.x against Pekko 1.1.x then we need to look at creating integration tests that use Pekko HTTP jars but that test with Pekko 1.0.x.
Sure I can do this, I actually had to do it before to diagnose a misleading MiMa false alarm, its not too hard to setup.
I asked in https://discord.com/channels/632150470000902164/922600050989875282/1196246949129629747 if there is a principled way to do this, otherwise I will add this capability to sbt-pekko-build using a technique similar to https://github.com/apache/incubator-pekko-connectors/pull/280#issuecomment-1807748739
Pekko Http built with Pekko Core 1.1.x will still work if you link against Pekko Core 1.0.x at runtime, I have already tested this
I think we should either drop support for Pekko 1.0 in Pekko HTTP 1.1, or keep building Pekko HTTP 1.1 against Pekko 1.0. I don't think we should build Pekko HTTP against Pekko 1.1 but still claim to support Pekko 1.0.
The problem with building against Pekko 1.1 but still claiming to support Pekko 1.0 is that it is really hard to avoid accidentally relying on stuff that is only in Pekko 1.1. I don't think 'testing' can protect us against that.
In contrast, if Pekko HTTP keeps depending on Pekko 1.0, it will also work with Pekko 1.1, as long as we have correctly adhered to our binary compatibility rules in Pekko. Here we are helped by the Scala compiler and tools such as MiMa, though having additional testing would of course still be welcome.
(mentioned before at https://lists.apache.org/thread/6stkdwh94tg9okbt4p28506s88q0mo5r)
I don't have a strong preference between building with Pekko 1.0 or dropping support for it.
So you mean we should do release a whole, eg 2024.04 release？
If we do this , we should remove the code for compatibility, eg with methodhandles
So you mean we should do release a whole, eg 2024.04 release？
I personally don't think updating a dependency minor version should require an update of the project major version.
The problem with building against Pekko 1.1 but still claiming to support Pekko 1.0 is that it is really hard to avoid accidentally relying on stuff that is only in Pekko 1.1. I don't think 'testing' can protect us against that.
There may be a tool that an help detecting this i.e. https://github.com/spotify/missinglink, currently looking into it it
I mean a bom for all pekko projects. @raboof
There is https://lists.apache.org/thread/zvr2bg028myz5yywprp7vkwp5xo9wptv
There are a few people asking about Slick 3.5 support and I was hoping to get onto releasing 1.1.0-M1 versions of our libs to sort this out but this issue is turning into a blocker on all release progress.
In practice, the mima filters show very few diffs between Pekko 1.0 and Pekko 1.1. My view is let's change the main branch builds to use 1.1 and document that it is strongly recommended not to mix Pekko 1.0 and 1.1 libs but that if you must, then you need to test the setup thoroughly.
In practice, the mima filters show very very diffs between Pekko 1.0 and Pekko 1.1.
I'm not sure if you meant 'very many' or 'very few', but if we added them to mima-filters, that means we have verified that they do not impact binary compatibility of the public APIs, right? That is what those filters are for.
My view is let's change the main branch builds to use 1.1 and document that it is strongly recommended not to mix Pekko 1.0 and 1.1 libs but that if you must, then you need to test the setup thoroughly.
That sounds fine to me.
In practice, the mima filters show very very diffs between Pekko 1.0 and Pekko 1.1. My view is let's change the main branch builds to use 1.1 and document that it is strongly recommended not to mix Pekko 1.0 and 1.1 libs but that if you must, then you need to test the setup thoroughly.
Im happy with this
In the meantime I can build an sbt plugin based on https://github.com/spotify/missinglink (the logic actually seems quite trivial) and if it works/is successful we can update the documentation to reflect its compatible.
A quick tl;dr is that plugin actually does static analysis on the JVM bytecode to figure out if your calling methods that don't exist for a specific dependency, i.e. it detects this precise problem
The problem with building against Pekko 1.1 but still claiming to support Pekko 1.0 is that it is really hard to avoid accidentally relying on stuff that is only in Pekko 1.1. I don't think 'testing' can protect us against that.
In a proper way
In practice, the mima filters show very very diffs between Pekko 1.0 and Pekko 1.1.
I'm not sure if you meant 'very many' or 'very few', but if we added them to mima-filters, that means we have verified that they do not impact binary compatibility of the public APIs, right? That is what those filters are for.
My view is let's change the main branch builds to use 1.1 and document that it is strongly recommended not to mix Pekko 1.0 and 1.1 libs but that if you must, then you need to test the setup thoroughly.
That sounds fine to me.
Apologies, I meant very few. I don't think anyone will notice any API diffs but I can't guarantee that if someone had a mix of dependencies coming from some Pekko 1.0 libs and some other Pekko 1.1 libs that there will not be problems. Netty and Protobuf are 2 dependencies where we have upgraded to newer versions where users with complicated dependency setups could find themselves running into trouble.
Apologies, I meant very few. I don't think anyone will notice any API diffs but I can't guarantee that if someone had a mix of dependencies coming from some Pekko 1.0 libs and some other Pekko 1.1 libs that there will not be problems. Netty and Protobuf are 2 dependencies where we have upgraded to newer versions where users with complicated dependency setups could find themselves running into trouble.
Yeah I was about to write a comment on this point but dropped it, however it is worth noting that as you said correctly there have been such significant changes in Pekko 1.1.x due to major dependency updates like netty and protobuf that there may have been some merit in officially dropping Pekko 1.0.x support I think thats a step too far.
If we are going to do such a step, we should do as many breaking but significant improvements and just release Pekko 2.0.x otherwise it just leads to confusion.
there may have been some merit in officially dropping Pekko 1.0.x support I think thats a step too far.
I guess at some point we should specify what we even mean with 'support' ;) . Perhaps we don't need to flesh this out in detail here and now, but I think it's totally reasonable to say 'we' still 'support' Pekko 1.0.x, but if you want to use Pekko HTTP 1.1.x, then you'll have to use it with Pekko 1.1.x or later.
Afaics currently our support is strictly SemVer, with stuff like behavioural breakages changes allowed as long as they are documented. Hence my reasoning behind collating all of these actually SemVer breaking changes into a Pekko 2.0.x.
We should not break SemVer often, and if we do it should be for a good reason.
As you rightly pointed out, other types of support need to be fleshed out as it all depends on what (as a community) we can commit to