Question to all users of NLog:
How should NLog.dll assembly be versioned after 1.0 is released? The
idea is to keep API backward compatible for all 1.x releases, but what
should assembly version numbers be?
a) Use 1.0.0.0 AssemblyVersion and AssemblyFileVersion for all 1.x releases
b) Use 1.0.0.0 for AssemblyVersion and use AssemblyFileVersion to
differentiate releases (for example 1.0.0.revision)
c) Use 1.0.0.revision for both AssemblyVersion and AssemblyFileVersion
d) Other?
What pros and cons of each approach do you see? I'd like to hear your
experiences with versioning assemblies in .NET so that we can make a
good decision. Do you use publisher policies, assembly binding
redirects, and so on?
I'd vote for a) or b) because having it you could easily replace
NLog.dll in already deployed applications. As NLog can configured
entirely from the configuration file this would give existing apps easy
upgrade path without the need of recompilation. But it breaks GAC and
who knows what else...
Another question: should the primary key for NLog.dll remain "open
source" (I believe it should, for exactly the same reason as keeping
things at v1.0.0.0 - easy replaceability of compiled assembly, even in
apps you don't have source code for).
I'm awaiting your comments.
--
Jarek Kowalski
http://blog.jkowalski.nethttp://www.nlog-project.org/ - A .NET Logging Library
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV_______________________________________________
Nlog-list mailing list
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list
