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
    to change to
    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.


Please note my new email address: da...@dannysung.com
POPT Library                                           http://rpm5.org
Developer Communication List                       popt-devel@rpm5.org

Reply via email to