BUG: versionNumberInFilename not evaluated correctly in >= TYPO3 v12.3

[FearFreddy]

I have checked that the bug exists in the dev-development branch Yes.

I have checked that there are no already open issues or recently closed issues about this bug Yes.

Describe the bug TYPO3 v12.3 has the following deprecation: https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/12.3/Deprecation-99810-VersionNumberedFilenameOptionNowBoolean.html.

This means that the value of $GLOBALS['TYPO3_CONF_VARS']['FE']['versionNumberInFilename'] is now a boolean, not a string value. But in the writeCachedMergedFileAndReturnTag function of the AssetService.php , this value is still "evaluated" against its old string options. Therefore, neither setting it to true (equivalent of previous embed option) nor to false (previously querystring) works, resulting in filenames without a timestamp in both cases.

Subsequently, all included stylesheets and scripts (using the v:asset.style and v:asset.script VHs) never change their filenames, even when making changes to them, and therefore browsers keep using their cached disk versions. This obviously can have some bigger implications, like when the HTML for a new feature is already visible to users, but important changes in css/js are missing because the browser is using old cached file versions.

To Reproduce Steps to reproduce the behavior:

1. Use TYPO3 v12.3 or higher, where the default value of $GLOBALS['TYPO3_CONF_VARS']['FE']['versionNumberInFilename'] is false
2. Include any script or stylesheet with the v:asset.script or v:asset.style ViewHelpers on your page
3. Look at the page in a browser that will cache your js/css files in disk/memory
4. Make a change to the css/js file(s) you included
5. Reload the webpage (not a hard reload), and notice that your changes are not reflected, because the filename of your included css/js files does not change and the browser cached the previous version

Expected behavior The filenames of the included css/js files should include a timestamp, using the previous querystring (= false) approach, so anytime a change is made to a css/js file, its filename changes too, and the browser is forced to completely re-load the file from scratch.

Workaround for now The issue can be fixed by manually setting/overwriting $GLOBALS['TYPO3_CONF_VARS']['FE']['versionNumberInFilename'] to any of its old string values in LocalConfiguration.php, AdditionalConfiguration.php or in an extension ext_localconf.php. Since it is just a deprecation for TYPO3 v12, it is still correctly evaluated everywhere else, and should not cause any issues.