Update changelog - #1358
Conversation
|
The failing CI has reminded me I want to try and track that down that crash before the new release since it only seems to occur on 4.3.7. |
| * Fixed blocking SQLite calls not being made in a GC free zone | ||
| * Fixed MinGW toolchain RC file handling | ||
|
|
||
| * Removed Haxe 3 support |
There was a problem hiding this comment.
Haxe 3.4.7 should still build fine, it's Haxe 3.3 support specifically that was removed in #1083 (and was probably already broken before).
There was a problem hiding this comment.
Does it actually work? My intent was to remove all Haxe 3 code paths. I'm happy to still have it say removed all Haxe 3 to stop someone trying to use it.
There was a problem hiding this comment.
Yes, Haxe 3.4.7 builds with nightly hxcpp and passes all Haxe unit tests, with the exception of this test that ended up being removed because it was incorrect:
https://github.com/HaxeFoundation/haxe/blob/bb7b827a9c135fbfd066da94109a728351b87b92/tests/unit/src/unit/TestReflect.hx#L114
I still have to sometimes compare behaviour with Haxe 3.4.7, and it is useful to be able to do that without having to dig out an old version of hxcpp. Lime also still supports Haxe 3.4.7 (until its next major release) and relies on being able to use modern hxcpp for it. Hxcpp's backwards compatibility is something that makes it a stable and reliable target.
I'm happy to still have it say removed all Haxe 3 to stop someone trying to use it.
I think the tool emitting a warning like "Haxe 3.4 support is deprecated and will be removed in a future hxcpp release" would be a more effective measure to encourage users to migrate than an inaccurate changelog entry.
2 participants
I've gone through the git log since the last time I updated the changelog and added all the missing stuff. In a day or two I'll merge this in and then take the resulting CI artefact and use that as a basis for a new haxelib release.