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
Nlog-list@...
https://lists.sourceforge.net/lists/listinfo/nlog-list
Some parts of this message have been removed.
Learn more about Nabble's 