NLog assembly version policy

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

NLog assembly version policy

Jarek Kowalski
Administrator
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.net
http://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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: NLog assembly version policy

amores perros



>From: Jaroslaw Kowalski To: nlog-list
>Subject: [Nlog-list] NLog assembly version policy
>Date: Thu, 03 Aug 2006 21:00:11 +0200
>
>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?
>

I'd vote for b, so that its public key doesn't have to change, but so
that you can tell which version you have (including in the GAC).



-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
fla
Reply | Threaded
Open this post in threaded view
|

Re: NLog assembly version policy

fla
This post was updated on .
CONTENTS DELETED
The author has deleted this message.
Reply | Threaded
Open this post in threaded view
|

Re: NLog assembly version policy

Jarek Kowalski
Administrator
François Lakraa wrote:
I vote for d.

Major.Minor.Revision.Build

Major : Backward compatibility may be compromised
Minor : Backward compatibility is supported
Revision : Typically when a bug correction occurs
Build : Let's VS generate it

The Assembly.info should contains 1.0.0.*

Then you should only promote Major.Minor.Revision, build is internal.

The worse is b. : too differents versions means GAC hell.
 
I use this policy for many financial software with great success.
This policy works great when you can recompile your entire project with the updated version of NLog. Assuming you have many EXEs and DLLs that use reference some version of NLog (like 1.0.0.10) what happens when you download a new NLog release that has the version set to 1.0.0.123.

Will it require a recompile?
An assembly redirect?
Publisher policy?

I'm not very familiar with GAC so I prefer private deployments. How do you deal with such issues?

Jarek

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
NLog Blog
Reply | Threaded
Open this post in threaded view
|

Re: NLog assembly version policy

Jarek Kowalski
Administrator
Jaroslaw Kowalski wrote:
François Lakraa wrote:
I vote for d.

Major.Minor.Revision.Build

Major : Backward compatibility may be compromised
Minor : Backward compatibility is supported
Revision : Typically when a bug correction occurs
Build : Let's VS generate it

The Assembly.info should contains 1.0.0.*

Then you should only promote Major.Minor.Revision, build is internal.

The worse is b. : too differents versions means GAC hell.
 
I use this policy for many financial software with great success.
This policy works great when you can recompile your entire project with the updated version of NLog. Assuming you have many EXEs and DLLs that use reference some version of NLog (like 1.0.0.10) what happens when you download a new NLog release that has the version set to 1.0.0.123.

Will it require a recompile?
An assembly redirect?
Publisher policy?

I'm not very familiar with GAC so I prefer private deployments. How do you deal with such issues?
I came up with a possible policy and I would like to hear your opinion on it:

a) Each version is: Major.Minor.Revision.Build

* Major - should be increased when we introduce source-level breaking change (code that uses old version of NLog doesn't compile against the new version) or any fundamental change are made to NLog core. Revision resets to zero after each increase.
* Minor - should be increased when we introduce IL-level breaking change (code compiled against old version of NLog doesn't work against new version), but maintaining source code compatibility (source code can be recompiled to work again). Changes to the target infrastructure (such as adding intermediate base classes or interfaces) might fit here. Revision resets to zero after each increase.
* Revision - should be increased when we add new public functionality (such as target/layout renderer) or fix some serious bug which changes the semantics of some target/layout renderer. Code taking advantage of revision X won't work for revisions <X.
* Build - should be synchronized to the Subversion revision number. Code compiled for A.B.C.D should also work for all A.B.C.* (modulo some minor bugfixes)

b) Each time we release a new OFFICIAL build (A.B.C.D) we'll provide a publisher policy that will redirect all versions [A.B.0.0 .. A.B.C.D) to the version A.B.C.D of NLog.dll. This can be placed in GAC so that old code will work. If we manage to maintain rule a) we should be pretty safe.

c) There should some easy option to "fake" a version number - rebuild newer NLog with older version number, so that code compiled against old NLog will work.

    Currently you need to:

    i) modify NLog.version
    ii) call nant updateversion
    iii) rebuild

d) Revision will jump by "1" for public releases only. Only one component of the version (Major,Minor,Revision) may increased be between official releases so if major or minor do change, revision resets back to zero.

e) Snapshots that add new features will share the same revision number, even though they may add new functionality each. They are meant for the adventurous who like to play with bleeding-edge stuff.

This might a sample versioning timeline:

1.0.0.1431 - public release of 1.0.0
1.0.0.1432 - minor bugfix (snapshot only)
1.0.0.1433 - minor bugfix (snapshot only)
1.0.0.1434 - minor bugfix (snapshot only)
1.0.1.1435 - new target added (snapshot only)
1.0.1.1436 - minor update (snapshot only)
1.0.1.1437 - minor update (snapshot only)
1.0.1.1438 - another target added (snapshot only - note that we're still 1.0.1, not 1.0.2)
1.0.1.1439 - yet another target added (snapshot only)
1.0.1.1440 - public release of 1.0.1
1.0.1.1441 - minor update (snapshot only)
1.1.0.1442 - IL-level breaking change introduced (snapshot only - note that we've reset revision to zero and increased minor)
1.1.0.1443 - minor update (snapshot only)
1.1.0.1444 - minor update (snapshot only)
1.1.0.1445 - new target (snapshot only - note that revision hasn't been increased because of point d) )
1.1.0.1446 - public release of 1.1.0
1.1.1.1447 - new target added (snapshot only)
1.1.1.1448 - another target added (snapshot only)
1.1.1.1449 - public release of 1.1.1

and so on...

What do you think? Some of my versioning assumptions may be naive and are based on purely theoretical knowledge of the GAC. I would like someone with practical experience to verify them.

Regards,

Jarek

-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Nlog-list mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/nlog-list
NLog Blog