You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4net-dev@logging.apache.org by Stefan Bodewig <bo...@apache.org> on 2016/09/09 04:28:00 UTC
Version Number
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
Building .NET Core Version (was Re: Version Number)
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-09-09, Dominik Psenner wrote:
> Would that work with nant? How does one compile a library that works
> on .net core anyway? Is there an extension for visual studio that adds
> a target framework?
As I don't use VS I don't know about this myself.
The .NET Core SDK comes with a "dotnet" CLI tool which I use via <exec>
from inside the NAnt build.
https://docs.microsoft.com/de-de/dotnet/articles/core/tools/dotnet
Right now it's using JSON for the project definition but IIUC future
versions of the .NET Core SDK will be heading "back" to msbuild and
.csproj files again.
Stefan
Re: Version Number
Posted by Dominik Psenner <dp...@gmail.com>.
On 9 Sep 2016 4:10 p.m., "Stefan Bodewig" <bo...@apache.org> wrote:
>
> On 2016-09-09, Dominik Psenner wrote:
>
> > 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 | ?
>
> This would leave us with only the last of four numbers that make up the
> version for indicating "our" version. I'm afraid I'd get confused by
> this immediately.
>
> > 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
>
> would work for me.
>
> > 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?
>
> No idea, it's what the pull request said :-)
>
> > Is the API radically different?
>
> No. Basically it is your usual log4net with some extension method stubs
> for missing framework APIs and without things like ASP.NET patterns or
> the ADO.NET appender. We really need to update the docs to reflect that.
>
> Stefan
Then this is yet another target framework that fits the versioning scheme
with the informational versioning attribute.
This leaves the topic of the ifdef hell that we need to accomplish the
task. Do we want to introduce csproj files that reflect the framework
targets? Would that work with nant? How does one compile a library that
works on .net core anyway? Is there an extension for visual studio that
adds a target framework?
Re: Version Number
Posted by Stefan Bodewig <bo...@apache.org>.
On 2016-09-09, Dominik Psenner wrote:
> 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 | ?
This would leave us with only the last of four numbers that make up the
version for indicating "our" version. I'm afraid I'd get confused by
this immediately.
> 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
would work for me.
> 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?
No idea, it's what the pull request said :-)
> Is the API radically different?
No. Basically it is your usual log4net with some extension method stubs
for missing framework APIs and without things like ASP.NET patterns or
the ADO.NET appender. We really need to update the docs to reflect that.
Stefan
Re: Version Number
Posted by Dominik Psenner <dp...@gmail.com>.
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