Good morning

There are quite a few options and the decision is interleaved with the infrastructure of hacking/build environment. Depending on how we deal with the different target frameworks in the future it might be wise to align versioning numbers along with the targeted framework. For example could we have:

framework  |  filename    | file version  |  informational version
---------------------------------------------------------------------------------------
.net 1.X        | log4net.dll | 1.2.1.0         | ?
.net 3.5        | log4net.dll | 3.5.0.1         | ?
.net 4.0        | log4net.dll | 4.0.1.5         | ?
.net 4.5        | log4net.dll | 4.5.0.1         | ?
.net 4.5.1     | log4net.dll | 4.5.1.1         | ?

Now if those assemblies all would map to one csproj in the log4net solution, we have absolute flexibility but also the burden to cherry pick patches to every project. Further I do not know how .net core fits into this versioning scheme.

Alternatively we could maintain backwards compatibility with older .net frameworks with a branching model. This requires us to change vcs to at least have better branching support, cherry picking, .. etc. Patching log4net is then a patch to the latest targeted framework along with a merge into all other branches (.net 1.X, .net 3.5, .net 4.0, .net 4.5, ..). The versioning number would be a common denominator and the informational version attribute could yield the target framework. For example:

framework  |  filename    | file version  |  informational version
---------------------------------------------------------------------------------------
.net 1.X        | log4net.dll | 2.0.6.0         | 2.0.6.0-.NET 1.X
.net 3.5        | log4net.dll | 2.0.6.0         | 2.0.6.0-.NET 3.5
.net 4.0        | log4net.dll | 2.0.6.0         | 2.0.6.0-.NET 4.0
.net 4.5        | log4net.dll | 2.0.6.0         | 2.0.6.0-.NET 4.5

Still, I do not see the impact of .net core support on log4net. Why does .net core support force us to release a 3.0.0 log4net assembly? Is the API radically different? Or is there just an API glue dll that makes log4net compatible with .net core? I do not know it and therefore I can just do wild guesses.

That's just my 2c.

On 2016-09-09 06:28, Stefan Bodewig wrote:
Hi

right now the "traditional" log4net assemblies of the next release would
be 1.2.16. The next nuget package would be 2.0.6 and the .NET Core
project creates 3.0.0. I'm confused by this. :-)

I'm not sure we need to allign all three versions but some consistence
would be good.

Any preferences?

Stefan

Reply via email to