Bump hex_core to v0.10.1 #335
Conversation
The spec in hex_core for hex_api_release:retire/4 indicates atoms are the keys for the retire reason (a map). Yet, we've always used strings and they continue to work.
The last CI I see for this is 8 months old. 24.3.4.17 is 2 months old. Might it be Erlang/OTP that changed something that caused that issue? Edit: maybe it'd also be a nice time to include 26 and 27 in CI? (if you prefer, though, I can do a separate pr for that); and potentially, while we're at it, |
|
|
||
| {profiles, [ | ||
| {test, [ | ||
| {extra_src_dirs, ["test/support"]}, | ||
| {overrides, [{override, rebar3,[{deps, [{erlware_commons, "1.3.1"}]}]}]}, | ||
| {deps, [{hex_core, "0.8.4"}, | ||
| {deps, [{hex_core, "0.10.1"}, |
There was a problem hiding this comment.
I'd get rid of this one. Doesn't rebar3 just accumulate deps in profiles (i.e. concatenate them with whatever's in the "default" profile)?
There was a problem hiding this comment.
I suspect this was put in play to test a different version from what rebar3 had, but in rebar3 it is now vendored.
There was a problem hiding this comment.
Agreed, this should be possible to take out.
|
@starbelly, I'm also gonna remove |
|
Once this one's merged I'll go ahead and rebase the others. |
Yes, let's get this merged and open up a tidy PR as a follow on, we also should modify CI to test on OTP 26/27 and stop testing 24. |
|
Good stuff. I already have a couple PRs lined up. I didn't remove '25' from tests, since "current-2" seems to be acceptable for OTP versions under test. At the same time, though, in one of the PRs, I did remove |
Updates to the latest hex_core. Oddly enough, a spec in hex_core that has never caused problems before caused problems today. The spec is here : https://github.com/hexpm/hex_core/blob/8a53ac8eddaf425cd70a41ae9279318063c01e67/src/hex_api_release.erl#L19
Not sure why now, but I'll open an issue in relevant places to sort it out.