A top-level requirement with a pre-release should allow matching pre-releases on any level

[ericmj]

By default the twiddle operator (~>) does not match pre-releases unless a pre-release is included in the version string: ~> 1.4.0-rc. This is a reasonable default because users usually do not want pre-release versions unless they explicit ask for it. Another constraint is that hex.pm does not allow packages to depend on pre-release dependencies unless the package itself is being published as a pre-release, because a package should not be regarded as a stable if its dependencies are not stable.

Phoenix 1.4.0-rc.0 was recently released which showed an issue with these constraints. Users that wan't to test the release candidate along with phoenix_live_reload would get a resolution error or get phoenix_live_reload resolved to a very old version when they declare these dependencies:

defp deps, do: [{:phoenix, "~> 1.4.0-rc"}, {:phoenix_live_reload, ...}]

This is because phoenix_live_reload declares it's dependency on phoenix as [...] ~> 1.3 which does not match 1.4.0-rc.0 according to the rules above. Users would have to add an override to phoenix or a pre-release version of phoenix_live_reload, with the requirement ~> 1.3-rc on phoenix, would have to be released. Neither are great solutions.

To fix this we should change the ~> operator to allow matching pre-releases at any level if the top-level project declared they want pre-releases with ~> 1.4.0-rc. This does not change the constraints on how packages are allowed to declare pre-release dependencies when published hex.pm.