Nlog: Next Version - NLog 5-6

[304NotModified]

As we have more than a year released pre-versions of NLog 5, and moved to NLog 4.5 in favor of NLog 5 (see #2445), the proposal is to skip NLog 5 and move to NLog 6 after NLog 4.x. This because many tutorials are written NLog 5 and that could be really confusing.

Old NLog 5 releases, almost 1 million downloads:

Please you're opinion :) (@snakefoot)

[snakefoot]

Yes it is very confusing with having a NLog 5.0 that never becomes final (which is mentioned many places to be the version to use for NetStandard/NetCore).

The promise of NLog 5.0 was NetStandard with minimum amount of breaking inteface changes. This has now changed into NLog 4.5 with no breaking interface changes.

I understand the great news that NetStandard was possible without breaking interface changes (Which is signaled with ver. 4.5). But explaining to the entire world that NLog 5.0 is not the correct version to use for a whole year until NLog ver. 6.0 is released is not a rewarding job. You also identified that it would be difficult to reuse NLog ver. 5 for doing breaking changes.

Maybe just bump the version to NLog 5.0 RTM, and mark all NLog 5.0 BETAS releases as obsolete? (Not sure how nuget works when requesting a non-existing pre-release, and a stable release is found).

I can see some NLog nuget packages continues to use NLog 2.0 as minimum version, and this is possible because there are very few breaking changes in the NLog-Target-interface, which I think is great. So people are navigating from NLog 2.0 to NLog 4.0 without thinking, so going to NLog 5.0 should not be a big deal.

P.S. Also hope that the NLog ver. 6.0 BETA stage will not be a year as well, since executing breaking changes and merging with main-branch is not gonna be fun for a long time (or error free).

[snakefoot]

Alternative then you need to be really quick and release NLog ver. 5.0 where everything has been sliced and diced to only include core-targets (MemoryTarget, AsyncTargetWrapper) and core-Layout (JsonLayout + SimpleLayout) and core-LayoutRenderers.

Everything else put into seperate NLog-packages (XmlConfig, exotic targets, exotic layouts). With the ability to easily register custom NLog-Config-Loaders (Like XmlConfig and soon to come JsonAppConfig).

Think NLog should focus on being a minimal package, as NetStandard have displayed how difficult it have been to do adapt. The Logging Framewok is the basis for many applications, and the year delay for NLog have caused several projects to abandon NLog because they could not move forward.

[304NotModified]

Yes it is very confusing with having a NLog 5.0 that never becomes final (which is mentioned many places to be the version to use for NetStandard/NetCore).

true, but it was also wierd to rename to 5.0 when a RC of 4.5 was released.

Maybe just bump the version to NLog 5.0 RTM, and mark all NLog 5.0 BETAS releases as obsolete? (Not sure how nuget works when requesting a non-existing pre-release, and a stable release is found).

We can only unlist packages and so the betas are still restorable.

I think it's too late for that, but what do you think about:

• The next version will be 5.0
• The changes are that small that there no betas are needed.
• We could then merge al the breaking changes PRs

P.S. Also hope that the NLog ver. 6.0 BETA stage will not be a year as well, since executing breaking changes and merging with main-branch is not gonna be fun for a long time (or error free).

That's the last thing I would like ;)

[snakefoot]

true, but it was also wierd to rename to 5.0 when a RC of 4.5 was released.

Think people have been using BETA and RC-versions because of need, not because they wanted to. Majority of people have been waiting for the RTM, and are not allowed to use pre-release-versions in production.

Going from NLog 4.4 RTM to NLog 5.0 RTM is not that weird. Think only the hardcore NetCore fans that have been riding the BETA-train.

[snakefoot]

We could also release NLog 5.0 with minimal breaking changes. Right after having released NLog 4.5

1757 - AsyncTargetWrapper - Change default overflow action to blocking

2069 - LayoutRenderer Initialize should swallow exceptions when configured

Fix some of the NLog 5 TODOs in code:

• Remove Caller-Properties from Fluent-interface, as they disturb structured logging
• Change NLog4J-Layout to not include non-standard NLog data by default, and remove duplicate properties.
• Remove LoggingConfiguration.ExceptionLoggingOldStyle

[snakefoot]

But it could be nice to remove the upper-version-nuget-restriction, since going forward it will only be an obstacle. And bumping the version would remove confusion around using an older NLog 5.0 BETA vs a newer NLog 4.5 RTM (Also for existing custom NLog-targets that requires NLog 5.0 or newer)

Anyway any choice is a good choice. Think people are waiting for the RTM-build.

[sandersaares]

I can confirm that as a user of NLog who creates NetStandard targeting software, I really do not care if it says 4 or 5 or 6 - all I want is to use a a stable version with NetStandard support.

From the standpoint of someone reading tutorials on the web that say to use v5, I agree that it can be confusing to have 4.5 as the actual proper version to be used to gain netstandard support. Probably some v5 or v6 should be released to help out such users who might be confused by this. Whether you go to v5 or skip it and go straight to v6 makes no difference to me from a user's viewpoint.

[304NotModified]

OK thanks,

FYI renaming 4.5 to 5 is out-of-scope. Unfortunately It's too late for that. So the discussion is if the next version should be 5 or 6

[snakefoot]

But you will remove the upper version cap from the nuget dependency for Nlog Extension Logging and Nlog Web? Because that is going to bite users really hard

[304NotModified]

But you will remove the upper version cap from the nuget dependency for Nlog Extension Logging and Nlog Web? Because that is going to bite users really hard

Do you mean remove the <5? Why is that needed? Do you mean "now" or in the future?

[JustArchi]

My opinion probably doesn't matter that much as I'm not heavily involved in the project but I'd also vouch for NLog 6 if anybody wants to hear my 5 cents. I've just recently realized that NLog 5 was "rebranded" to NLog 4.5, so it makes sense to drop it for good and make people use either 4.5 or 6.0 - just to avoid my own confusion at least.

[snakefoot]

Do you mean remove the <5? Why is that needed? Do you mean "now" or in the future?

I mean when NLog 4.5 RTM is out on the street, and work is started on breaking things.

I have have been bitten several times by dependency restrictions, so I only use them as last resort at the consuming application level. Logging libraries are usually at the bottom of the stack, and having dependency restriction at this level affects the entire stack.

[c0shea]

I don't know how the v5 betas compare to the 4.5 RC, but to me if the publicly-facing API doesn't have all that many changes then I'd say using v5 would be fine. However, if there are more than a couple small inconsistencies between the two, as a client I think it would be less confusing to jump to v6 to avoid any expectations of similarity. Though v5 isn't RTM, it's been in the beta stage for so long that I imagine many who needed the netstandard support have treated it as such.

[ppumkin]

It already really confusing which version works with which other version. Logging just used to work now I have all sorts of unnecessary problems and I have no idea what to use any more. (dotnet core)

Ahh right.. since I had 5 installed I could not roll back down to 4.5 - Visual Studio was throwing a s**t fit - i had to uninstall everything and redo it.

The error is as follows and you just need to man handle it back into 4.5.x (and yes.. the package was uninstalled but it still complains about this downgrade)

Install-Package : Detected package downgrade: NLog from 5.0.0-beta05 to 4.5.0-rc03. Reference the package directly from the project to select a different version.

Hope it works..!?

[snakefoot]

@304NotModified I think it's too late for that, but what do you think about:

• The next version will be 5.0
• The changes are that small that there no betas are needed.
• We could then merge al the breaking changes PRs

Like the idea of using NLog 5.0 for making minor breaking changes, that doesn't affect custom Targets or custom Layouts.

Then NLog 5.0 would be the last monolith build, and NLog 6.0 will be the one that breaks everything into small packages (NLog-core and everything else).

[304NotModified]

Like the idea of using NLog 5.0 for making minor breaking changes, that doesn't affect custom Targets or custom Layouts.

Then NLog 5.0 would be the last monolith build, and NLog 6.0 will be the one that breaks everything into small packages (NLog-core and everything else).

👍 OK that's the plan then :)

[304NotModified]

@ppumkin is it clear now or should we explain more? PS: If you experience problems, please create a new github issue, thx!

[304NotModified]

will close this issue if I changed the milestones the current PRS to V5/V6

[sandersaares]

Is there any timeline for publishing a stable version of the current RC? I am most eager to get rid of the prelease tags on libraries that reference NLog 4.5 RC.

[304NotModified]

Currently the main task is updating the docs and writing docs about structured logging.

There is not ETA for that yet.

FYI There will be a rc4 soon with some small changes, see milestone

[snakefoot]

@304NotModified Can you give an example of what kind of docs you are looking for about structured logging, besides those written at https://messagetemplates.org/ ?

[304NotModified]

@snakefoot moved this to https://github.com/NLog/NLog/issues/2432#issuecomment-356707996

[304NotModified]

Closing this one, in summary:

• we don't gonna rename 4.5 to 4
• there will be a NLog 5 version, and will have small breaking changes. No big features.
• NLog 6 will break NLog into multiple packages.

[304NotModified]

FYI up-to-date todo list for NLog 4.5 is here: https://github.com/NLog/NLog/issues/2498