Point taken - I realise this stuff is time consuming. On the other
hand, we only have to address it once, and then come up with a set of
rules for the project.
The link I provided suggests some rules for using -version-info:
http://www.gnu.org/software/libtool/manual.html#Versioning
There are some choices to be made, maybe they've been taken already, so
I'll summarise the proposals:
a) Unique interface number for every ActiveMQ-CPP release, e.g:
2.1.1 = 2:0:0
2.1.2 = 3:0:0
2.2.0 = 4:0:0
3.0.0 = 5:0:0
...
Under this scheme, an application built with 2.1.1 will refuse to link
with 2.1.2 at runtime. This is clearly very paranoid - but it will
work. In a system like Debian or Red Hat, this is not very practical -
if a user has two applications, one of which was built with 2.1.1 and
the other was built with 2.1.2, then the user will need to have both
versions of the library. In practice, both applications may work with
2.1.2.
b) More complicated:
- major releases (2.x, 3.x) break binary compatibility
- minor releases (2.1.x, 2.2.x) may add new function prototypes, but
without breaking binary compatibility
- patches (2.1.1, 2.1.2 etc) make no change to the interface
(-version-info current:revision:age)
2.1.1 = 2:0:0
2.1.2 = 2:1:0 ; notice the revision number is incremented
2.1.3 = 2:2:0 ; notice the revision number is incremented again
2.2.0 = 3:0:1 ; a new function is added, so binary compatibility with
2:x:x is preserved - therefore, the `age' is incremented
2.2.1 = 3:1:1
2.3.1 = 4:0:2 ; age is incremented again, to ensure compatibility
with 3:x:x and 2:x:x (current - age = 4 - 2 = 2, therefore 2:x:x is
compatible)
3.0.0 = 5:0:0 ; function prototype arg list changed - binary
compatibility broken: age is reset to 0, because there is no compatibility
with 4:x:x or earlier
Using the second approach requires more discipline - whenever a release
occurs, someone needs to decide if this is this a patch, a minor release
or a major release. However, the results are much better - for example,
applications built with 2:1:0 will happily link at runtime with 2:2:0 or
3:0:1. Therefore, the user can install 2.3.1 on their system, delete
2.2.1, and continue using their applications without re-compiling.
Regards,
Daniel
--
-----------------------------------------------------------------------
Ready Technology Limited
Incorporated in England and Wales, 4940731
Registered office: Devonshire House, 60 Goswell Rd, London, EC1M 7AD
-----------------------------------------------------------------------
