-
Notifications
You must be signed in to change notification settings - Fork 37
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set currentVersion
in PekkoCoreDependency
to 1.1.0-M1
once M1 is released
#419
Comments
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. |
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 apache/pekko-connectors#280 (comment) |
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 |
I personally don't think updating a dependency minor version should require an update of the project major version. |
I mean a bom for all pekko projects. @raboof |
There may be a tool that an help detecting this i.e. https://github.com/spotify/missinglink, currently looking into it it |
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. |
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.
That sounds fine to me. |
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
In a proper way |
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. |
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 |
I think we can start to keep versions in sync from 2.0 |
this is done |
As stated in apache/pekko#857 specifically
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.The text was updated successfully, but these errors were encountered: