Library version proposal

#1

Here is a problem which I feel many people have: I have working code, leave a project alone and then look at it again. And now - because of changes to OpenFL/Lime, things do not run anymore (i.e. compile or runtime errors). Sometimes figuring out what needs to change etc is just not very practical, when all you want to do is to make some minor changes. What could help a lot here is if the project.xml file would optionally induce a version number for libraries, as in:

<haxelib name="openfl" version="5.4.1">

Ideally, the compiler could even use this version to compile.

What does everybody think? @singmajesty?

#2

It is already supported. http://www.openfl.org/lime/docs/project-files/xml-format/

#3

Sorry to be a buzzkill but I think the compiler doesn’t explicitly use the specified version.
It merely complains in case that version isn’t installed.
See this thread: http://community.openfl.org/t/control-lime-version-per-project/1276/13

#4

Thanks - so i must have overlooked that. However, as the next poster says, this does not cover all the issues.

#5

What kind of issues did you experience?

Current releases of OpenFL should support locking versions if you set your Lime version first, like this:

<haxelib name="lime" version="5.5.0" />
<haxelib name="openfl" version="6.1.2" />

We use haxelib in order to resolve library dependencies. We added “wildcard dependency” support to haxelib and submitted a pull request, but so far there does not appear to be interest on the part of the project to merge this in. Having wildcard version support would allow OpenFL to import a matching version of Lime automatically (instead of the current behavior, which is to throw an error if the version does not match)

The issue is that including only OpenFL with a version, still pulls the currently set Lime version… without wildcard versioning, OpenFL cannot specify a Lime version range to import

#6

Good to know. I guess what I really would want is an automatic record (maybe in the .build file) for the versions used. A while ago someone asked how to figure out which versions were used in older code and it seems there was no easy way to identify. It would be great to have an “automatic record” somewhere without having to set versions manually.

1 Like
#7

We’re thinking of writing a manifest of copied files to help with future builds (removing automatically copied files)

If we do, that would help give some insight to what versions were used.

2 Likes
#8

Is there any advance with this? I mean it could be great to know if there is a place to look for the versions of each part in the compilation that you are using (haxe, lime, openfl, actuate, google play games, android ndk, gradle version, build tools, gradle plugin, …), so when updates come you can have a look to which version you where using. I am new making version control and I found it really useful since Google is always updating and some stuff break without any idea about the reason.

#9

Haxelib supports local haxelib repositories. It would be possible to create a local repository to go with a project and commit it all to version control together. There is a proposal for a version lock system in the future for Haxe though I do not see a timeline on it being implemented

Perhaps a simple README or text file with a record of all the versions you are using would suffice to help keep track of this?

#10

The README text is a good idea, I am used to have a look to haxelib lists to know which versions of my local and external repository I am using but for example how can I know which version of gradle, android build toolds, gradle build tools or Google Play Games is the one used by default since those default usually change every new update.
For example, yesterday I got some issues (I couldn’t compile without code changes) because I didn’t know which Android AdMob version I was using by default but suddenly (I suppose) gradle decided to change to number 19.6.0 for any reason and it uses queries tag that as far as I know we don’t support at the moment since we are using Android 8 and those queries are supported from Android 11.
It took me a while to know that I could set Android AdMob to version 19.3.0 for removing that problem.
I mean I saw that control version is completely necessary. So at the moment apart from haxelib which other text files I should have a look to know the versions I am using?
Thanks for everything @singmajesty

#11

As a workaround to this issue, I use fully separate Haxe installations for each project, So I’ve installed a copy of Haxe 3.4.7 for a console game I’m working on at C:/HaxeToolkit/3.4.7_ProjectA/ and have a separate 4.0.5 installation for a PC game I’m working on at C:/HaxeToolkit/4.0.5_ProjectB/.

Meanwhile, I set up my OS’s Environment Variables to switch between them, so instead of HAXEPATH being C:\HaxeToolkit\haxe, it’s: C:\HaxeToolkit\%HAXE_VERSION%\haxe and I just change HAXE_VERSION to the subfolder name when I move between projects. It’s a bit of a hassle to set up each time I start a new project because the Haxe installer messes with it, but it’s worth it.

It helps when a project needs to be archived, too, since I can move its Haxe installation folder to that project’s location for archiving, or just leave it in place if I ever need it again.

Ultimately, it’s a bit of an odd workaround, and sorta wasteful when there’s code overlap, but it’s become a necessary workflow for me because inevitably every project I do ends up needing some dev or hacked versions of a library that other projects aren’t using, don’t need, or can’t use. And I never have to keep track of which versions of which libraries I’m using on each project.

I’ve often thought I should make a proposal to the HaxeFoundation folks to support something like this officially, at least to the point where you can more easily have multiple Haxe versions on one machine, a la Unity Hub or the AIR SDK.

#12

Another solution is to clone HaXe repository and commit your project specific changes to a branch, so you can keep track of all modifications (and merge them to other branches if needded).

#13

I’m looking forward to this proposal if it happens