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.
tobil4sk
left a comment
tobil4sk
left a comment
There was a problem hiding this comment.
In general, I wonder the best way to handle the Haxe 5 api in this next hxcpp release. Really it is experimental/unstable support for Haxe 5, and will likely break again in future nightly haxe before the final haxe 5 release. Maybe it is worth having a separate part of the changelog for haxe 5 related additions, mentioning that they are still subject to change.
Also, I know this hasn't been done previously, but since some of the entries are reworded from the original commit messages, it would be useful to have links to the commit/PR for reference. I can help with this if needed.
| * Added typed semaphore API | ||
| * Added override attributes to relevant functions | ||
| * Added HXCPP_GENERATE_MSVC to generate a Visual Studio solution | ||
| * Added String::fromCharCode to encode UTF16 surrogates unchanged |
There was a problem hiding this comment.
This one is more of a bug fix than an addition
| * Updated zlib to 1.2.13 | ||
| * Updated sqlite to 3.51.2 | ||
| * Updated zlib to 1.3.1 | ||
| * Updated tracey to 0.13.1 |
There was a problem hiding this comment.
Tracey is a new feature, so I think it makes more sense to say the version in the "Added" entry than to say it was updated
| * Fixed Pointer.ofArray with empty array | ||
| * Fixed semaphores and condition variables not having GC free zones around blocking calls | ||
| * Fixed HXCPP_DEBUG_LINK and HXCPP_OPTIMIZE_LINK not being respected on Linux | ||
| * Fixed UTF8 output in Windows consoles |
There was a problem hiding this comment.
| * Fixed UTF8 output in Windows consoles | |
| * Fixed unicode output in Windows consoles |
UTF8 isn't really involved at all here, the unicode strings are currently utf-16 encoded and go straight to the windows console without conversion: #1307
|
|
||
| * Fixed SSL socket non blocking handshake throwing an exception on 64bit Windows | ||
| * Fixed Windows 64bit architecture detection | ||
| * Fixed critial error handler returning the wrong callstack |
|
Also zlib needs to be updated too by merging this pr(#1356) and then the change version of zlib from 1.3.1 to 1.3.2 in the changelog. |
3 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.