Pseudo-Breaking Changes

[FriedrichWeinmann]

There are a few things I once decided one way, that turned out to be ... less than ideal patterns.
On the other hand, changing them now would be a breaking change, a major "No you don't" in PSFramework: Ideally, a module built six years ago on PSFramework should still run on today's version without issues.
And on the then-current version 5 years into the future.

So, nothing major will be considered without significant need, but ... I'll collect minor changes that would be good to change after all.
In all cases, mitigations should be available long before, and a path back where viable.

Set-PSFLoggingProvider waits automatically

Currently, when defining a new logging provider, it will not by default wait until it is ready in the background and instead move on. Which in some cases has lead to lost log messages. This was fixed with the -Wait switch parameter.

Planned Change

The -Wait switch will be enabled by default.

Impact & Mitigation

If you are planning on utilizing the time between configuration and creation, this will add additional performance costs (in no more than the seconds range). This is particularly noteworthy if you register multiple logging providers in sequence, as the wait will happen for each provider instance.

You can intentionally disable the wait by specifying -Wait:$false where you intentionally wish to not wait. This will work now and be respected in the new implementation.

FileSystem Provider will gain CSV headers.

THIS DOES NOT AFFECT THE LOGFILE PROVIDER, USED FOR REGULAR LOGFILES!

Currently, the automated debug-log log files are generated without CSV headers.
This can already now be enabled with the PSFramework.Logging.FileSystem.ModernLog setting.

Planned Change

Change the default value of the setting to $true

Impact & Mitigation

Anybody currently automatically processing those logs in their default state will have an unexpected extra-line in their results, as they previously treated all lines as data and the first one will then become header.
By explicitly defining the configuration setting to $false this can be prevented, as the defaults will not overwrite intent. On the other hand, if you are managing this, you could update your parsing and set it to $true when ready, to enjoy a better experience and better performance/reliability.

Logfile Provider will add a leading empty line in json mode

Currently, the logfile logging provider when configured for json files will add a leading empty line to it.
This can already now be disabled by setting the JsonNoEmptyFirstLine configuration setting.

Planned Change

Change the default value of the setting to $true

Impact & Mitigation

Anybody automatically processing the json-based logfiles will no longer need to skip the first line. Continuing to do so may instead lead to missing out on that first line in your results.
You can switch to the new behavior to migrate this at your own pace, or explicitly set it to $false to prevent the change from happening to you and stay with the current behavior.