As a middleware/plugin developer, we offer support for the last 3 stable releases of Unreal Engine. In 6.0, UE_LOG is marked as deprecated in favour of UE_LOGF, but UE_LOGF was only introduced in UE 5.8.
This means upon the release of UE 6.0, there will be a point at which it is impossible to support the last 3 stable releases of Unreal Engine:
- UE 6.0: UE_LOG can’t be used without a deprecation warning being emitted
- UE 5.8: OK - UE_LOG/UE_LOGF both exist
- UE 5.7: UE_LOGF not defined
I would ask that UE_LOG emitting a deprecation warning is deferred until 6.2, since logging is extremely pervasive within any code base, and effectively writing every UE_LOG statement twice with a conditional preprocessor guard + alternate format syntax is a significant maintenance burden. If the deprecation warning is deferred until 6.2, this would allow us to continue using UE_LOG for 6.0 (5.7, 5.8 and 6.0 all use UE_LOG), switch to UE_LOGF after the release of 6.1 (5.8, 6.0 and 6.1 can then all use UE_LOGF), and have all of our code migrated to UE_LOGF in time for the release of 6.2.
(For what it’s worth, I did attempt to wrap UE_LOG/UE_LOGF in a macro that routes differently based on the char type of the format string for older engine versions, but it’s just too impractical to handle UTF-8 format strings on 5.7 and earlier where FUtf8String::Printf doesn’t yet accept the format string as UTF-8)
[Attachment Removed]
Hi June, we need UE_LOG to be deprecated on our end to stop the influx of new call sites, which were coming in at an average of 40/day. We announced UE 5.9 last month at Unreal Fest Seoul, which means UE_LOGF will be available in 3 releases at the point that 6.0 is released. Does that address your concerns? Alternatively, UE_LOGFMT has been available since maybe UE 5.3 and could be used instead; though its primary limitation is that it doesn’t support format specifiers until 6.0.
[Attachment Removed]
Hi June, I would recommend in that case that you have a branch ready to go with your logging call sites updated, in advance of the release of 6.0, such that you can release your update concurrently with our release of 6.0. I acknowledge that this will add overhead on your end to maintain such a branch, especially if you want to support 6.0 Early Access alongside 5.7 through 5.9. We have Engine/Extras/UnsupportedTools/ConvertUELog/ConvertUELog.py that the eventual release notes will recommend as a means of migrating existing logging call sites. It is the same script that we used to update more than 95% of our over 150,000 logging call sites.
Another option, which I have seen work elsewhere, is to wrap our logging macros with your own, and have your wrapper forward to UE_LOG on 5.7. In the period where you support versions older than 5.8, you would need to pass either %hs or %ls for every string argument, never %s, and avoid using %hs for UTF-8 arguments because that wasn’t supported until 5.8.
[Attachment Removed]
I think we would also need 5.10 to exist, otherwise there is no overlap time between 5.7 being dropped and 6.0 needing to be supported. We have over 4000 logging call sites which need to be manually updated, so it’s not going to be a fast process to do that migration.
UE_LOGFMT not supporting the format specifiers means it’s not very useful. If it was just stripping the TEXT() wrapper around the formatting string away, that would be something we could handle with a macro. But there’s no practical way to change the format specifiers within the format string based on the engine version.
I understand the need to prevent new call sites occurring in Unreal Engine upstream. Maybe there could be an option or define that can be set for modules to turn off the deprecation warning for UE_LOG in those modules? That way we can turn that option on and buy ourselves more time. (We could of course turn off all deprecation warnings via pragmas, but I don’t want to turn off all deprecation warnings - just the one for UE_LOG)
[Attachment Removed]