I agree. I have no problems with breaking binary&source compatibility
especially if that change will make popt better/easier in the future.
But a change in name seems necessary for app developers to make that
choice. eg. what happens if you're building mulitiple different
software packages... both dynamically linking popt, but one uses 1.x and
the other 2.x? The header files would also need something like #include
<popt2/popt2.h> or something like that. Can't say I particularly like
it... but it does those issues somewhat cleanly.
I don't think it's that bad for developers to switch over. Old apps may
take a while. But people will know (especially if you put "#warning
popt-1.x is deprecated" in the headers for 1.x. =) ). And will move new
software over. Look at things like libxml2.
Ideally, however, popt2 should include mechanisms that allow for future
versions to do this sort of versioning check at runtime. So this popt2
actually becomes popt ABI 2.0. Not popt-2.0. (eg. popt3 may still use
popt2 ABI.. but then again with all the versioning there may never need
to be a popt3 =) ).
On 6/7/2010 9:51 AM, Wayne Davison wrote:
On Mon, Jun 7, 2010 at 9:40 AM, Jeff Johnson <n3...@mac.com
<mailto:n3...@mac.com>> wrote:
The added tyrrany of forcing every application that currently has
-lpopt
to change to
-ljdod
will be rate-determining to adoption (and glacially/tectonically
slow imho)
For me, if popt 2 is not compatible with popt 1 then I would rather have
to make a conscious choice to upgrade my code (testing it for
compatibility), and having to change the libray name as a part of that
is pretty minor. Having a possibility for my program to be run-time
linked with a library that is not compatible with what it expects would
be very bad, imo.
..wayne..
--
Please note my new email address: da...@dannysung.com
______________________________________________________________________
POPT Library http://rpm5.org
Developer Communication List popt-devel@rpm5.org
