I think we can resolve this with wildcard version support. For one Lime release, I included a custom version of haxelib to add this feature, but I reverted it in fear that it would clobber studios that maintain (and need) their own custom version of haxelib. I have a fork of haxelib with support for wildcard versioning and local directories (similar to dev, but it does not “override always”)
The good news is the haxelib included with Haxe 3.4.2 and greater currently supports
haxelib dev haxelib path/to/custom/haxelib, and current Lime tools support
lime rebuild haxelib, or you can
haxe client.hxml from the root directory of a custom haxelib project.
If you have wildcard version support, then OpenFL can include
<haxelib name="lime" version="5.0.*" /> (and similar) instead of using whatever the current version is.
I do not want to force OpenFL to pair directly to minor releases of Lime, in case we release a patch for Lime.
Current OpenFL releases should also allow you to include Lime before OpenFL (with your own version) first, which should help a bit with deadlock:
<haxelib name="lime" version="5.0.1" />
<haxelib name="openfl" />
For what it is worth, I re-released OpenFL 3.6.1, hard-coding Lime 2.9.1 as the version.
What really needs to happen, though, is OpenFL 4 or OpenFL 5 support in Flixel