POCO C++ Libraries

"" With the current scheme, we'll have to increment the number with
"" every minor release, and we'll probably soon arrive at 10.

So? Whats wrong with that?

"" Also, there's no connection to the actual POCO version number.

Why does there need to be?

"" The traditional .so versioning scheme does not really work with POCO,
because we cannot
"" guarantee that minor bugfix releases are binary compatible.

I think "traditional" versioning where you use the same .so version number
as the library itself doesn't make a lot of sense with C++. You might want
to look at the libtool versioning guidelines for some ideas:

http://www.gnu.org/software/libtool/manual.html#Libtool-versioning

But I'd suggest just a single, monotonically increasing version number
that changes whenever a breaking change is made to an existing interface.

libversion was set to 3 for 1.3.0 (it was 2 for 1.2.x).
I have set the version number for 1.3.1 to 4, since there are some minor
incompatible changes.

I am not perfectly happy with the current numbering scheme, maybe we
should adopt a different one (e.g. libPocoFoundation.so.1.3.1???) Any
comments? With the current scheme, we'll have to increment the number with
every minor release, and we'll probably soon arrive at 10. Also, there's no
connection to the actual POCO version number. The traditional .so
versioning scheme does not really work with POCO, because we cannot
guarantee that minor bugfix releases are binary compatible.