Skip to content
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

Fail fast on Akka version mismatch #1538

Closed
johanandren opened this issue Nov 21, 2017 · 10 comments
Closed

Fail fast on Akka version mismatch #1538

johanandren opened this issue Nov 21, 2017 · 10 comments
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted help wanted Identifies issues that the core team will likely not have time to work on
Milestone

Comments

@johanandren
Copy link
Member

When getting an older Akka version pulled into a project than what is supported by/works with Akka HTTP you get missing method errors etc but would be nice if we instead could check on load of the extension and fail fast with a nice error message saying "You have Akka 2.x.y in your class path but need at least Akka version 2.a.b".

@ktoso ktoso added 1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted help wanted Identifies issues that the core team will likely not have time to work on labels Nov 21, 2017
@ktoso
Copy link
Member

ktoso commented Nov 21, 2017

There's two main case:

  • akka http is compiled against akka 2.4.X yet user uses Akka less than 2.4X (in sbt that would get evicted and the later version would win, though not so much in some cases in maven it seems)
    • then we want to fail hard I guess, since they run at the risk of blowing up in runtime due to internals requiring 2.4.X features
  • akka http 10 being used with 2.4
    • just log a warning or suggestion that the user should upgrade akka and akka streams to 2.5.[latest], and link to the docs why this works

Once 10.1 is out the latter one becomes the first one.

This has to be implemented by putting a compile build time akka-version value in the

package akka.http
object Version 

object (this already exists, just add the akka version in there too). And the check being performed on actor system load / start

@johanandren
Copy link
Member Author

johanandren commented Nov 21, 2017

Maybe we should even provide something from Akka core to make this easy for any library built with/on top of Akka? Akka.requireAtLeastVersion(fromLibrary)

@ktoso
Copy link
Member

ktoso commented Nov 21, 2017

Hm, sounds fun actually. Since we have a number of satelite projects

@patriknw
Copy link
Member

Ping. I think this is important for Akka HTTP 10.1.0 since dependencies are provided and now we have the utility in Akka.

@johanandren
Copy link
Member Author

I'll PR this

@johanandren
Copy link
Member Author

Not as straight forward as it seems.

The version require utility was introduced in 2.5.10 which means that if we start using it, we do not in fact support Akka HTTP 10.1.x is (binary) compatible with Akka 2.5.x as the docs says, maybe this is fine and we should just change the docs, but I'm not sure, would like a second opinion here.

@patriknw
Copy link
Member

We will never support all of 2.5.x all the way to 2.5.0, because sometimes we have to add things (e.g. in akka-stream) that are needed in akka-http. That's why we need to set a minimum supported version. For 10.1.0 I think it's fine to pick the latest and greatest 2.5.10. Later we will probably be conservative and only bump the minimum when really needed (or at least have some lag of a few patch versions).

@ktoso
Copy link
Member

ktoso commented Mar 13, 2018

This was merged

@ktoso ktoso closed this as completed Mar 13, 2018
@ktoso ktoso added this to the 10.1.0 final milestone Mar 13, 2018
@johanandren
Copy link
Member Author

What's the PR it was merged in, because my PR was just closed.

@ktoso
Copy link
Member

ktoso commented Mar 13, 2018

Oh :/ Sneezed my brain out today it seems

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
1 - triaged Tickets that are safe to pick up for contributing in terms of likeliness of being accepted help wanted Identifies issues that the core team will likely not have time to work on
Projects
None yet
Development

No branches or pull requests

4 participants